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SUMMARY OF CHANGES FOR LY20-0893-2 FOR VM/SP RELEASE 3 


Modules DMSQRY and DMSDOS split 


The modules DMS@RY and DMSDOS have been split. DMSQRY was split 
into the following modules: DMSQRS, DMS@RT, DMSQRU, DMSQRV, 
DMSQ@RW, DMSQRX, DMSQ@RY, and DSMQRZ. 


DMSDOS handles CMS/DOS SVC requests. DMSDOS passes control to 
the appropriate module to handle the SVC. The following modules 
handle the SVC functions: DMSETR, DMSGMF, DMSGTM, DMSGVE, 
DMSLCK, DMSLDF, DMSLIC, DMSMCM, DMSRPG, DMSSTX, DMSSUB, DMSSVL, 
DMSVIS, and DMSXCP. 


CMS Enhancements - IUCV 


CMS now supports IUCVY communication. The two newW macros, 
HNDIUCY and CMSIUCV, enable programs to invoke IUCV functions. 
These macros also allow the user to specify exits for any IUCV 
external interrupts that occur on the path. CMS support allows 
multiple subsystems/applications to use IUCV functions within a 
virtual machine. 


( System Product Interpreter Information 


The System Product Interpreter processing is described. All 
modules associated with the System Product Interpreter are 
documented. 


New CMS commands 


CATCHECK command: A new CMS command that allows VSAM users to 
invoke the VSE/VSAM Catalog Check Service Aid to verify a 
catalog structure. 


RESERVE command: A new CMS commands that allocates all 
available blocks of a 512-, 1K-, 2K-, or 4%K-byte block formatted 
minidisk to a unique CMS file. DMSRSV processes this command. 


IMMCMD command: <A new CMS command that establishes and cancels 
immediate commands. This command should be issued only from 
EXECs. DMSIMM processes this command. 

EXECOS command: A new CMS command that resets the 0S and VSAM 


environments under CMS without returning to the interactive 
environment. DMSSTG processes this command. 


New CMS Macros 


ABNEXIT macro: A new CMS macro that sets or clears abend exit 
routines. DMSABX processes this macro. 


WAITECB macro: A new CMS macro that waits on an ECB or a list 
of ECBs. DMSWTE processes this macro. 


IMMCMD macro: A new CMS macro that declares, clears, and 
{ queries immediate commands. DMSIMM processes this macro. 


TEOVEXIT macro: A new CMS macro that sets up and clears a CMS 
tape end-of-volume exit. 
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New CMS function 


DISKID function: A new CMS function that obtains information on 
the physical organization of a minidisk - the virtual address; 
the blocksize, and the offset of the RESERVEd minidisk. 


Modified CMS cummands and macros 


IDUMP 


NUCXLOAD command: A nucleus extension with the ENDCMD attribute 
specified receives control at normal end-of-command processing. 


FORMAT command: This command now allows you to specify a 
512-byte block minidisk. 


RDTERM macro: The RDTERM macro with the TYPE=DIRECT attribute 
specified indicates that a line is to be read directly from the 
virtual machine console. 


VSE IDUMP macro will be simulated by CMS/DOS using the PDUMP 
support. The IDUMP macro produces a dump containing information 
about the failing component. The CMS IDUMP support is invoked 
whenever a program product issues the VSE IDUMP macro. 


CMSSEG was eliminated 


PROP Enhancements 


Miscellaneous 


CMSSEG was eliminated and the code was merged into the CMS 
Nucleus. 


To support the new enhancements to PROP, the following modules 
were added: DMSPOL, DMSPO@, and DMSPOS. 


Minor technical and editorial changes have been made throughout 
this publication. 
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This publication provides the IBM system hardware and software 
support personnel with the information needed to analyze 
problems that may occur on the IBM Virtual Machine/System 
Product (VM/SP) when used in conjunction with VM/370 Release 6. 


HOW THIS MANUAL IS ORGANIZED 


This manual is one of two volumes: 
e Volume 1. VM/SP Control Program (CP) 
e Volume 2. Conversational Monitor System (CMS) 


Each volume contains logic descriptions for the designated 
components of VM/SP. Each of these volumes is divided into four 
sections: Introduction, Method of Operation, Directory, and 
Diagnostic Aids. 


The method of operation and program organization sections 
contain the functions and relationships of the program routines 
in VM/SP. They indicate the program operation and organization 
in a general way to serve as a guide in understanding VM/SP. 
They are not meant to be a detailed analysis of VM/SP 
programming and cannot be used as such. 


The directory contains a table of the CMS modules and their 
entry points. 


The diagnostic aids sections contain additional information 
useful for determining the cause of a problem. 


Appendix A, located in Volume 2, contains a description of the 
CMS macro library. 


Appendix B, also located in Volume 2, describes the CMS/DOS 
macro library. 


Appendix C, also located in Volume 2, describes CMS/DOS support 
modules. 


Information on the Remote Spooling Communications Subsystem 
CRSCS), a VM/370 Release 6 component, is contained in: 


IBM VM/370 System Logic and Program Determination Guide, 


Volume 3 Remote Spooling Communications Subsystem (RSCS), 
SY20-0888 


The control blocks supportive of the RSCS Logic are contained 
in: 


VM/SP_ Data Areas and Control Block Logic, Volume 2 (CMS), 
LY24~-5221 


gic Information on the Interactive Problem Control System 


Lo 
CIPCS), a VM/370 Release 6 component is totally contained in: 


VM/SP_ Service Routines Program Logic, LY20-0890 


HOW TO USE THIS MANUAL 


° Isolate the component of VM/370 in which the problem 
occurred. 


e Use the list of restrictions in VM/SP System Messages and 
Codes to be certain that the operation that was being 
performed was valid. 
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DEVICE TERMINOLOGY 


Use the directories, VM/SP Data Areas and Control Block 
Logic, Volume 1 (CP), and VM/SP Data Areas and Control Block 
Logic, Volume 2 (CMS) to help you to isolate the problem. 


Use the method of operation and program organization 
sections, if necessary, to understand the operation that was 
being performed. 


The following terms in this publication refer to the indicated 
support devices: 


"2305" refers to IBM 2305 Fixed Head Storage, Models 1 and 
2. 


"270x" refers to IBM 2701, 2702, and 2703 Transmission 
Control Units or the Integrated Communications Adapter CICA) 
on the System/370 Model 135. 


"FB~-512" refers to those IBM DASD devices implementing the 
fixed-block (512-byte blocks) architecture. Specifically, 
they are the IBM 3310, and the IBM 3370. Current IBM disk 
storage devices are referred to as count-key-data DASD when 
it is important to distinguish between count-key-data DASD 
and FB-512. Otherwise, they are collectively referred to as 
DASD or disk. 


"3330" refers to the IBM 3330 Disk Storage, Models l, 2, or 
11; the IBM 3333 Disk Storage and Control, Models 1 or 11; 
and the 3350 Direct Access Storage operating in 3330/3333 
Model 1 or 3330/3333 Model 11 compatibility mode. 


"3340" refers to the IBM 3340 Disk Storage, Models A2, Bl, 
and B2, and the 3344 Direct Access Storage Model B2. 


"3350" refers to the IBM 3350 Direct Access Storage Models 
A2 and B2 in native mode. 


"3380" refers to the IBM 3380 Storage Facility. Information 
on the IBM 3380 Storage Facility is for planning purposes 
only until the availability of the product. 


73704," "3705," or %370X" refers to IBM 3704 and 3705 
Communications Controllers. 


The term "3705" refers to the 3705 I and the 3705 II unless 
otherwise noted. 


"2741" refers to the IBM 2741 and the 3767, unless otherwise 
specified. 


"3270" refers to a series of display devices, namely the IBM 
3275, 3276, 3277, 3278, and 3279 Display Stations. A 
specific device type is used only when a distinction is 
required between device types. 


The term, System/370 processors, is also applicable to 4300 
processors and 303x series processors unless indicated 
otherwise. 


Information about display terminal usage also applies to the 
IBM 3036, 3138, 3148, and 3158 Display Consoles when used in 
display mode, unless otherwise noted. 


Any information pertaining to the IBM 3284 or 3286 also 
pertains to the IBM 3287, 3288 and the 3289 printers, unless 
otherwise noted. 


"3262" refers to the IBM 3262 Printer, Models 1 and ll. 
Information on the IBM 3262 Printer, Models 1 and ll, is for 
Ceoneene purposes only, until the availability of the 
product. 
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Unless otherwise noted, the term "VSE" refers to the 
combination of the DOS/VSE system control program and the 
VSE/Advanced Functions program product. 


In certain cases, the term DOS is still used as a generic term. 
For example, disk packs initialized for use with VSE or any 
predecessor DOS or DOS/VS system may be referred to as DOS 
disks. 


The DOS like simulation environment provided under the CMS 
component of the VM/System Product, continues to be referred to 
as CMS/DOS. 


PREREQUISITE PUBLICATIONS 


Virtual Machine/s m Produc 
Introduction, GC19-6200 
Terminal Reference, GC19-6206 
CMS Command and Macro Reference, $C19-6209 
CMS User's Guide, $C19-6210 


COREQUISITE PUBLICATIONS 


Virtual Machine/System Product 
Operator's Guide, $C19-6202 
CP_ Command Reference for General Users, SC19-6211 
System Programmer's Guide, S$C19-6203 
system Messages and Codes, 5C19-6204 
OLTSEP and Error Recording Guide, $C19-6205 
Operating Systems in a Virtual Machine, GC19-6212 
Service Routines Program Logic, LY20-0890 
Data Areas and Control Block Logic, Volume 1 (CP), LY24-5220 


ata Areas and Control Block Logic, Volume (CMS), 
LY24-5221 


In addition, for EREP processing the following OS/VS Library 
publications are required: 


IBM OS/VS, DOS/VSE, VM/370 Environmental Recording Editing and 
Printing CEREP) Program, GC28-0772 


IBM OS/VS, DOS/VSE, VM/370 Environmental Recording Editing and 
Printing CEREP) Program Logic, SY28-0773 


SUPPLEMENTARY PUBLICATIONS 


IBM System/360 Principles of Operation, GA22-6821 
IBM System/370 Principles of Operation, GA22-7000 
IBM OS/VS, DOS/VS, and VM/370 Assembler Language, GC33-4010 
IBM OS/VS_ and VM/370 Assembler Programmer's Guide, GC33-4021 
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RELATED PUBLICATION 
[BM Virtual Machine Facilityv/370 Remote Spooling 3 
Fommunications Subsystem (CRSCS ser's ide, GC20-1816 
CE F T 
CMS/DOS is part of the CMS system and is not a separate system. 
The term CMS/DOS is used in this publication as a concise way of 
stating that the DOS simulation mode of CMS is currently active; 
that is, the CMS command 
SET DOS ON 
has been previously issued. 
The phrase "CMS file system” refers to disk files that are in 


CMS's 512-, 800-, 1024-, 2048-, and 4096-byte block format; 
CMS's VSAM data sets are not included. 
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This section contains the following information: 


| ) 
e 


Conversational Monitor System (CMS) 
Interrupt Handling in CMS 
Functional Information 

OS Macro Simulation Under CMS 

VSE Support Under CMS 


Section 1: Introduction to CMS 
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The Conversational Monitor System (CMS), the major subsystem of 
VM/SP, provides a comprehensive set of conversational facilities 
to the user. Several copies of CMS may run under CP, thus 
providing several users with his own time sharing system. CMS 
is designed specifically for the VM/SP virtual machine 
environment. 


Each copy of CMS supports a single user. This means that the 
storage area contains only the data pertaining to that user. 
Likewise, each CMS user has his own machine configuration and 
his own files. Debugging is simpler because the files and 
storage area are protected from other users. 


Programs can be debugged from the terminal. The terminal is 
used as a printer to examine limited amounts of data. After 
examining program data, the terminal user can enter commands on 
the terminal that alter the program. This is the most common 
method used to debug programs that run in CMS. 


CMS, operating with the VM/SP Control Program, is a time sharing 
system suitable for problem solving, program development, and 
general work. It includes several programming language 
processors, file manipulation commands, utilities, and debugging 
aids. Additionally, CMS provides facilities to simplify the 
operation of other operating systems in a virtual machine 
environment when controlled from a remote terminal. For 
example, CMS creates and modifies job streams and analyzes 
virtual printer output. 


Part of the CMS environment is related to the virtual machine 
environment created by CP. Each user is completely isolated 
from the activities of all other users, and each machine where 
CMS executes has virtual storage available to it and managed for 
it. The CP commands are recognized by CMS. For example, the 
commands allow messages to be sent to the operator or to other 
users and allow virtual devices to be dynamically detached from 
the virtual machine configuration. 


THE CMS COMMAND LANGUAGE 


THE FILE SYSTEM 


The CMS command language offers terminal users a wide range of 
functions. It supports a variety of programming languages, 
service functions, file manipulation, program execution control, 
and general system control. For detailed information on CMS 
commands, refer to the ¥M/SP CMS Command and Macro Reference. 


Figure 11 on page 60 describes CMS command processing. 


The Conversational Monitor System interfaces with virtual disks, 
tapes, and unit record equipment. The CMS residence device is 
kept as a read-only, shared, system disk. Permanent user files 
may be accessed from up to 25 active disks. CMS controls the 
logical access to these virtual disks, while CP facilities 
manage the device sharing and virtual-to~real mapping. 


User files in CMS are identified with three designators. The 
first is filename. The second is filetype. The filetype may 
imply specific file characteristics to the CMS file management 
routines. The third is filemode. The filemode describes the 
location and access mode of the file. 


The compilers available under CMS default to particular input 


filetypes, such as ASSEMBLE, but the file manipulation and 
listing commands do not. Files of a particular filetype form a 
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logical data library for a user. For example, the collection of 
all COBOL source files, or of all object (TEXT) decks, or of all 
EXEC procedures. This allows selective handling of specific 
groups of files with minimum input by the user. 


User files can be created directly from the terminal with the 
VM/SP System Product Editor. The VM/SP System Product Editor 
provides extensive context editing services. File 
characteristics such as record length, record format, and tab 
locations can be specified. The VM/SP System Product Editor 
also provides full screen support for 3270 display stations. 


The major highlights of this editor include: 

° Multiple views of the same or different files 

e Selective column viewing 

e Automatic wrapping of lines larger than the screen 


e Ability to issue selected commands directly from the 
displayed line 


e Ability to define screen format 
e Extended string search functions 
° Column pointing for editing within a line 


Additionally, the VM/SP System Product Editor provides language 
expansions and flexibility through the EXEC 2 processor and the 
System Product interpreter. Figure 2 on page 5 describes the 
modules that perform the processing for the new editor. 


CMS automatically allocates compiler work files at the beginning 
of command execution on whichever active disk has the greatest 
amount of available space, and then CMS deallocates them at 
completion. Compiler object decks and listing files are 
normally allocated on the same disk as the input source file or 
on the primary read/write disk, and they are identified by 
combining the input filename with the filetypes TEXT and 
LISTING. These disk locations may be overridden by the user. 


CMS disk files contain records stored on disks as 5l2-, 8&00-, 
1024-, 2048-, or 4096-byte records. For disks with 800-byte 
records a single user file is limited to a maximum of 65,533 
records and must reside on one virtual disk. The maximum number 
of files is limited by the file management system to 3400. For 
disks with 1024-, 2048-, and 4096-byte records, a single user 
file is limited to a maximum of 2714-1 CMS blocks and must reside 
on one virtual disk. The maximum number of data blocks 
available in a variable format file on a 512-byte blocksize 
minidisk is about 15 times less than 2°1-1. This number is the 
maximum number of data blocks that can be accessed by the CMS 
file system due to the 5 level tree structure. The maximum 
number of files on any one disk is limited by the file 
management system to 27!-1. However, the actual number of files 
is limited by the available disk space and the size of the user 
files. 
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SUBCOMMANDS 
*Note 1. CDELETE, CHANGE, COMPRESS, COPY, COUNT, COVERLAY, DELETE, DUPLICATE, EXPAND, LOWERCAS, 
MERGE, MOVE, OVERLAY, RECOVER, SHIFT, UPPERCAS. 
*Note 2. CMSG, CURSOR, EMSG, FILE, LPREFIX, MSG, PFILE, PRESERVE, PSAVE, PURGE, READ, REFRESH, RENUM, 


REPEAT, RESET, RESTORE, SAVE, SET POINT, SET SCREEN, SET TERMINAL, TYPE. 
Figure 2. Module Flow for the VM/SP System Product Editor 
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All CMS disk files are written as 512-, 800-, 1024-, 2048-, or 
4096-byte records chained together by a specific master file 
entry that is stored in a table called the file directory; a 
separate file directory is kept for, and on, each virtual disk. 
The data records may be discontiguous, and are allocated and 
deallocated automatically. <A subset of the file directory 
(called the user file directory) is made resident in virtual 
storage when the disk directory is made available to CMS. It is 
updated on the virtual disk at least once per CMS command if the 
status of any file on that disk has been changed. 


Virtual disks may be shared by CMS users; the facility is 
provided by VM/SP to all virtual machines, although a user 
interface is directly available in CMS commands. Specific files 
may be spooled between virtual machines to accomplish file 
transfer between users. Commands allow such file manipulations 
as writing from an entire disk or from a specific disk file to a 
tape, printer, punch, or the terminal. Other commands write 
from a tape or virtual card reader to disk, rename files, copy 
files, and erase files. Special macro libraries and text or 
program libraries are provided by CMS, and special commands are 
provided to update and use them. CMS files can be written onto 
and restored from unlabeled tapes via CMS commands. 


Caution: Multiple write access under CMS can produce 
unpredictable results. 


Problem programs which execute in CMS can create files on 
unlabeled tapes in any record and block size; the record format 
can be fixed, variable, or undefined. Figure 3 describes the 
file system for an 800-byte record on disk. Figure 24% on page 
101 shows the file system for 512-, 1K-, 2K-, and 4K-byte 
records on disk. 


DMSNUC Area of Storage Free Storage Disk Storage 
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.Figure 3. File System for an 800-Byte Record on Disk 
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The Conversational Monitor System includes commands to create, 
compile, modify, and correct source programs; to build test 
files; to execute test programs; and to debug from the terminal. 
The commands of CMS are especially useful for OS and VSE program 
development, but the commands also may be used in combination 
with other operating systems to provide a virtual machine 
program development tool. 


CMS utilizes the OS and VSE compilers via interface modules; the 
compilers themselves normally are not changed. To provide 
suitable interfaces, CMS includes a certain degree of OS and VSE 
simulation. The sequential, direct, and partitioned access 
methods are logically simulated; the data records are physically 
kept in the chained fixed-length blocks, and they are processed 
internally to simulate OS data set characteristics. CMS 
supports VSAM catalogs, data spaces, and files on OS and DOS 
disks using the Access Method Services portion of VSE/VSAM. 05S 
Supervisor Call functions such as GETMAIN/FREEMAIN and TIME are 
simulated. The simulation restrictions concerning what types of 
0S object programs can be executed under CMS are primarily 
related to the OS/PCP, MFT, and MVT Indexed Sequential Access 
Method CISAM) and the telecommunications access methods. 
Functions related to multitasking in OS and VSE are ignored by 
CMS. For more information, see "0S Macro Simulation under CMS" 
and "VSE Support under CMS." 
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INTERRUPT HANDLING IN CMS 


$VC_ INTERRUPTIONS 


CMS receives virtual SVC, input/output, machine, program, and 
external interruptions and passes control to the appropriate 
handling program. 


The Conversational Monitor System is SVC Csupervisor call) 
driven. SVC interruptions are handled by the DMSITS resident 
routines. Two types of SVCs are processed by DMSITS: internal 
linkage SVC 202 and 203, and any other SVCs. The internal 
linkage SVC is issued by the command and function programs of 
the system when they require the services of other CMS programs. 
(Commands entered by the user from the terminal are converted to 
the internal linkage SVC by DMSINT). The OS SVCs are issued by 
the processing programs (for example, the Assembler). 


INTERNAL LINKAGE SVCS 


OTHER SVCS 


When DMSITS receives control as a result of an internal linkage 
SVC €202 or 203), it saves the contents of the general 
registers, floating-point registers, and the SVC old PSW, 
establishes the normal and error return addresses, and passes 
control to the specified routine. (The routine is specified by 
the first 8 bytes of the parameter list whose address is passed 
Dae 1 for SVC 202 or by a halfword code following SVC 
203. 


For SVC 202, if the called program is not found in the internal 
function table of nucleus Cresidant) routines, then DMSITS 
attempts to call in a module (a CMS file with filetype MODULE) 
of this name via the LOADMOD command. 


If the program was not found in the function table, nor was a 
module successfully loaded, DMSITS returns an error code to the 
caller. 


To return from the called program, DMSITS restores the calling 
program's registers, and makes the appropriate normal or error 
return as defined by the calling program. 


The general approach taken by DMSITS to process other SVCs 
supported under CMS is essentially the same as that taken for 
the internal linkage SVCs. However, rather than passing control 
to a command or function program, as is the case with the 
internal linkage SVC, DMSITS passes control to the appropriate 
routine. The SVC number determines the appropriate routine. 


In handling non-CMS SVC calls, DMSITS refers first to a 
user-defined SVC table Cif one has been set up by the DMSHDS 
program). If the user-defined SVC table is present, any SVC 
number Cother than 202 or 203) is looked for in that table. If 
it is found, control is transferred to the routine at the 
specified address. 


If the SVC number is not found in the user-defined SVC table (Cor 
if the table is nonexistent), DMSITS either transfers control to 
the CMSDOS shared segment Cif SETDOS ON has been issued), or the 
standard system table (contained in DMSSVT) of OS calls is 
searched for that SVC number. If the SVC number is found, 
control is transferred to the corresponding address in the usual 
manner. If the SVC is not in either table, then the supervisor 
call is treated as an abend call. 
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The DMSHDS initialization program sets up the user-defined SVC 
table. It is possible for a user to provide his own SVC 
routines. 


INPUT/OUTPUT INTERRUPTIONS 


All input/output interruptions are received by the I/0 interrupt 
handler, DMSITI. DMSITI saves the I/0 old PSW and the CSW 
(channel status word). It then determines the status and 
requirements of the device causing the interruption and passes 
control to the routine that processes interruptions from that 
device. DMSITI scans the entries in the device table until it 
finds the one containing the device address that is the same as 
that of the interrupting device. The device table (DEVTAB) 
contains an entry for each device in the system. Each entry 
for a particular device contains, among other things, the 
address of the program that processes interruptions from that 
device. 


When the appropriate interrupt handling routine completes its 
processing, it returns control to DMSITI. At this point, DMSITI 
tests the wait bit in the saved I/0 old PSW. If this bit is 
off, the interruption was probably caused by a terminal 
Casynchronous) I/0 operation. DMSITI then returns control to 
the interrupted program by loading the I/0 old PSW. 


If the wait bit is on, the interruption was probably caused by a 
non-terminal Csynchronous) I/0 operation. The program that 
initiated the operation most likely called the DMSIOW function 
routine to wait for a particular type of interruption Cusually a 
device end). In this case, DMSITI checks the pseudo-wait bit in 
the device table entry for the interrupting device. If this bit 
is off, the system is waiting for some event other than the 
interruption from the interrupting device; DMSITI returns to the 
oaks nari s loading tha saved I/0 old PSW. (This PSW has the 
wal it on. 


If the pseudo-wait bit is on, the system is waiting for an 
interruption from that particular device. If this interruption 
is not the one being waited for, DMSITI loads the saved I/0 old 
PSW. This will again place the machine in the wait state. 
Thus, the program that is waiting for a particular interruption 
will be kept waiting until that interruption occurs. 


If the interruption is the one being waited for, DMSITI resets 
both the pseudo-wait bit in the device table entry and the wait 
bit in the I/0 old PSW. It then loads that PSW. This causes 
control to be returned to the DMSIOW function routine, which, in 
turn, returns control to the program that called it to wait for 
the interruption. 


TERMINAL INTERRUPTIONS 


Terminal input/output interruptions are handled by the DMSCIT 
module. All interruptions other than those containing device 
end, channel end, attention, or unit exception status are 
ignored. If device end status is present with attention and a 
write CCW was terminated, its buffer is unstacked. An attention 
interrupt causes a read to be issued to the terminal, unless 
attention exits have been queued via the STAX macro. The 
attention exit with the highest priority is given control at 
each attention until the queue is exhausted; then a read is 
issued. Device end status indicates that the last I/O operation 
has been completed. If the last I/O operation was a write, the 
line is deleted from the output buffer and the next write, if 
any, is started. If the last I/O operation was a normal read, 
the buffer is put on the finished read list and the next 
operation is started. If the read is caused by an attention 
interrupt, the line is first checked to see if it is an 
immediate command (built-in or user-defined). If it is a 
user-defined immediate command, control is passed to a user 
specified exit, if one exists. Upon completion, the exit 
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returns to DMSCIT. If it is a built-in immediate command CHX, 
for example), appropriate processing is performed by DMSCIT. 
Unit exception indicates a canceled read. The read is reissued, 
unless it had been issued with ATTREST=NO, in which case unit 
exception is treated as device end. 


NTERRUPTION 


Interruptions from these devices are handled by the routines 
that actually issue the corresponding I/0 operations. When an 
interruption from any of these devices occurs, control passes to 
DMSITI. Then DMSITI passes control to DMSIOW, which returns 
control to the routine that issued the I/0 operation. This 
routine can then analyze the cause of the interruption. 


Cc T UPTION 


Interrupts from devices under user control are serviced the same 
as CMS devices except that DMSIOW and DMSITI manipulate a 
user-created device table, and DMSITI passes control to any 
user-written interrupt processing routine that is specified in 
the user device table. Otherwise, the processing program regains 
control directly. 


PROGRAM INTERRUPTIONS 


RNA T 


CHEC 


The program interruption handler, DMSITP, receives control when 
@ program interruption occurs. When DMSITP gets control, it 
stores the program old PSW and the contents of ragisters 14, 15, 
0, 1, and 2 into the program interruption element (PIE). (CThe 
routine that handles the SPIE macro instruction has already 
placed the address of the program interruption control area 
(PICA) into PIE.) DMSITP then determines whether or not the 
event that caused the interruption was one of those selected by 
a SPIE macro instruction. If it was not, DMSITP passes control 
to the DMSABN abend recovery routine. 


If the cause of the interruption was one of those selected in a 

SPIE macro instruction, DMSITP picks up the exit routine address 

from the PICA and passes control to the exit routine. Upon 

return from the exit routine, DMSITP returns to the interrupted 

program by loading the original program check old PSW. The 

eoct ese field of the PSW was modified by a SPIE exit routine in 
e : 


UPTIONS 


T 


An external interruption causes control to be passed to the 
external interrupt handler DMSITE. If the user has issued the 
HNDEXT macro to trap external interrupts, DMSITE passes control 
to the user's exit routine. If the interrupt was caused by the 
timer, DMSITE resets the timer and types the BLIP character at 
the terminal. The standard BLIP timer setting is two seconds, 
and the standard BLIP character is uppercase, followed by the 
lowercase Cit moves the typeball without printing). Otherwise, 
control is passed to the DEBUG routine. 


RUPTIONS 


Hard machine check interruptions on the real processor are not 

reflected to a CMS virtual user by CP. A message prints on the 
consola indicating the failure. The user is then disabled and 

must IPL CMS again in order to continue. 
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The most important thing to remember about CMS, from a debugging 
standpoint, is that it is a one-user system. The supervisor 
manages only one user and keeps track of only one user's file 
and storage chains. Thus, everything in a dump of a particular 
machine relates only to that virtual machine's activity. 


You should be familiar with register usage, save area 
structuring, and control block relationships before attempting 
to debug or alter CMS. 


REGISTER USAGE 

When a CMS routine is called, Rl must point to a valid parameter 
list (PLIST) for that program. On return, RO may or may not 
contain meaningful information (for example, on return from a 
call to FILEDEF with no change, RO contains a negative address 
if a new FCB has been set up; otherwise, it contains a positive 
address of the already existing FCB). R15 contains the return 
code, if any. The use of registers 0 and 2 through 11 varies. 
On entry to a command or routine called by SVC 202 the following 
are in effect: 
Register Contents 

0 The address of EPLIST, if available. 

1 The address of the PLIST supplied by the caller. 

12 The address entry point of the called routine. 

13 The address of a work area (12 doublewords) supplied 

by SVCINT. 

14 The return address to the SVCINT routine. 

15 The entry point (same as register 12). 
On return from a routine, Register 15 contains: 
Return Code Meaning 

0 No error occurred 

<0 Called routine not found 

>0 Error occurred 
If a CMS routine is called by an SVC 202, registers 0 through 14 
are saved and restored by CMS. 
Most CMS routines use register 12 as a base register. 

UC F STGRAG 


Figure 4 on page 16 describes how CMS uses its virtual storage. 
The pointers indicated (MAINSTRT, MAINHIGH, and FREELOWE) are 
all found in NUCON Cthe nucleus constant area). 


DMSFRE handles requests for CMS free storage. The sections of 
CMS storage have the following uses: 


DMSNUC (X*°00000° to X*'05000"). 
This is the nucleus constant area. It contains pointers, 
flags, and other data updated by the various system routines. 
Low-Storage DMSFREE User Free Storage Area (X"05000" to 
X"0E000"). 


This area is a free storage area, where user requests to 
DMSFREE are allocated. i 
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Transient Program Area (X*OE000" to X*°10000°). 
Since it is not essential to keep all nucleus functions 
resident in storage all the time, some of them are made 
"transient." This means that when they are needed, they are ; | 
loaded from the disk into the transient program area. Such 
programs may not be longer than two pages, because that is the 
size of the transient area. (CA page is 4096 bytes of virtual 
storage.) All transient routines must be serially reusable 
Since they are not read in each time they are needed. 


se A DMSFREE Nucleus Free Storage Area (X’°10000" to 
This area is a free storage area where nucleus requests to 
DMSFREE are allocated. The top part of this area contains the 
dummy hyperbloks for the S and Y disks. Each block is 48 
bytes long. This area may be followed by the file status 
tables for the S2 filemode files of the system disk and the Y2 
filemode files of the system disk extension. 


If the system disk is formatted as 512, 1K, 2K, or 4K blocks, 
then each FST is 64 bytes (X'40') long and holds approximately 
318 FSTs. If the system disk is formatted in 800-byte blocks, 
then each FST is 40 bytes (X'28') long and holds approximately 
509 FSTs. If there is enough room, the FREETAB table also 
occupies this area, just below the file status tables, if they 
are there. Each entry in the FREETAB table is one byte long. 
Each byte represents one page (4K or 4096 bytes) of defined 
storage. 


User Program Area (X‘°20000" to Loader Tables or CMS nucleus, 
Whichever has the lowest value). 
User programs are loaded into this area by the LOAD command. 
Storage allocated by means of the GETMAIN macro instruction is 
taken from this area, starting from the high address of the 
user program. In addition, this storage area can be allocated 
from the top down by DMSFREE, if there is not enough storage 
available in the low-storage DMSFREE storage area. Thus, the | 
usable size of the user program area is reduced by the amount 
of free storage that has been allocated from it by DMSFREE. 


Loader Tables (Top pages of storage). 
The top of storage is occupied by the loader tables, which are 
required by the CMS loader. These tables indicate the modules 
that are currently loaded in the user program area (Cand the 
transient program area after a LOAD command). The size of the 
loader tables can be varied by the SET LDRTBLS command. 
However, to successfully change the size of the loader tables, 
the SET LDRTBLS command must be issued immediately after IPL. 


CMS Nucleus (location is a system installation option; suggested 
location is (X°70000" - "X'MB). 
These segments contain the reentrant code for the CMS nucleus, 
shared copies of the system S-STAT, and the system S-disk and 
Y-disk FST tables, respectively. If there is not sufficient 
room to contain these tables, the S-STAT is placed in 
low~storage DMSFREE Nucleus Free Storage area. The CMS system 
is designed to operate as a saved system, shared among all 
users of the CMS system. The CMS nucleus code in such a 
shared system must be reentrant and may not be modified under 
any circumstances. 


If the size of the user's virtual machine is defined below the 
ending location of the CMS nucleus (refer to label NUCSIGMA in 
Figure 5 on page 17 ), it is not possible to IPL by device name. 
This is because the CMS nucleus is too large to be loaded into 
the user's virtual storage. Therefore, the user can only IPL by 
the system name (such as IPL CMS). The loader table is placed 
immediately below the CMS nucleus. 


On the other hand, if the size of the user's virtual machine is 
defined above the ending location of the CMS nucleus (see 
Figure 6 on page 18), the user may IPL by either device name or 
system name. 
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IPLing by device name: 


The S-STAT, Y-STAT, and the loader table are placed above the 
CMS nucleus. If there is not enough room to contain the S-STAT 
and Y-STAT above the CMS nucleus (NUCSIGMA), they are placed in 
low storage. Likewise, if there is not sufficient room for the 
loader table above the CMS nucleus (CNUCSIGMA), it is placed 
below the nucleus. Any leftover free space above the nucleus is 
placed on the high DMSFREE chain. 


IPLing by system name: 


The shared copy of the S-STAT, Y-STAT and the nucleus is used. 
The loader table is placed above the S-STAT and Y-STAT 
CNUCOMEGA) if there is sufficient room. If there is not 
sufficient room to contain the loader table above the S-STAT and 
Y-STAT, it is placed below the nucleus. Any leftover free space 
above the S-STAT and Y-STAT CNUCOMEGA) is placed on the high 
DMSFREE chain. 
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VIRTUAL STORAGE 
| ‘x'MB 
NECOMESA S-STAT and Y-STAT 
(Shared) 
NUCSIGMA 
CMS Nucleus 
(Shared) 
OS simulation, EXEC, EXEC 2, REXX, XEDIT, CMS 
interrupt handlers, file system, free storage management, 
loader, device 1/0, debug. 
*X'MB - 
X’'70000’ =-Yyer "1 
NUCALPHA Storage Key = X’F’ or X‘0 
END OF STORAGE 
E 
MMGIe System Loader Table 
(Size determined by set LDRTBLS command) 
Storage Key = X'F’ 
iDMSFREE requests when no more low storage is available 
Storage Key = X’E’ or X'F’ 
FREELOWE aS eae aE ae a 
Unused portion of User Program Area 
MAINHIGH _-_ oO _—--— er Orr er 


GETMAIN requests 


Storage Key = X’E’ 
MAINSTRT ee ee 
The User’s Program CMSSAVE CMSCB FSTB 


(Program is located via the LOAD command) 


Storage Key = X’E’. 


X'20000' 
Low Storage DMSFREE Nucleus Free Storage 
Area. The upper part of this area may contain the 
S-STAT and/or the Y-STAT, followed by the 
FREETAB, if there is enough room. 
Storage Key = X’‘F’ 
X'10000’ 
Transient Program Area 
Storage Key = X’E’ 
X’EO00’ : : 
Low Storage DMSFREE User Free Storage Area 
X’5000" Storage Key = X’E’ 
DMSNUC 
System Control Blocks, flags constants, and pointers 
XO! Storage Key = X‘F’ * 


* The page starting at X’4000’ containing OPSECT, SUBSECT, 
DBGSECT, DMSERL, TSOBLKS, USERSECT, and free 
storage has a Storage Key = X‘E’. 


Figure 4. CMS Storage Map 1. Storage Map 1 describes CMS virtual storage usage when 
the CMS nucleus is larger than the user's virtual storage. In this case, 
you must IPL by system name (VMSIZE is less than NUCSIGMA). (The arrows 


indicate that MAINHIGH is extended upward and FREELOWE is extended 
downward. ) 
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VM SIZE 
'X'MB 


NUCOMEGA 


NUCSIGMA 


‘X'MB- 
X’70000' 
NUCALPHA 


FREELOWE 


MAINH!GH 


MAINSTRT 


X’20000' 


X'10000’ 


X'E000' 


| x’5000' 


X’0’ 


Figure 5. 
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VIRTUAL STORAGE 


S-STAT and Y-STAT 


(Shared — if IPL’d by system name) 


CMS Nucleus 
(Shared — if IPL’d by system name) 


~OS simulation, EXEC, EXEC 2, REXX, XEDIT, CMS 
interrupt handlers, file system, free storage management, 
loader, device |/O, debug. 


Storage Key = X‘F’ or X‘0’ 


System Loader Table 
(Size determined by set LDRTBLS command) 


Storage Key = X‘F’ 
DMSFREE requests when no more low storage is available 


Storage Key = X’E’ or X'F’ 


Unused portion of User Program Area 
CONTROL BLOCKS IN FREE STORAGE 


CMSSAVE CMSCB FSTB 


Storage Key = X’E’ 


GETMAIN requests 


Storage Key = X‘E’ 


The User's Program 
(Program is located via the LOAD command) 


Storage Key = X’E’ 


Low Storage DMSFREE Nucleus Free Storage 
Area. The upper part of this area may contain the 
S-STAT and/or the Y-STAT, followed by the 
FREETAB, if there is enough room. 


Storage Key = X’F’ 
Transient Program Area 
Storage Key = X’E’ 


Low Storage DMSFREE User Free Storage Area 


Storage Key = X’E’ 


DMSNUC 
System Control Blocks, flags, constants, and pointers 


Storage Key = X’F’ * 


* The page starting at X’4000’ containing OPSECT, 
SUBSECT, DBGSECT, DMSERL, TSOBLKS, 
USERSECT, and free storage has a Storage Key = 
X’E’. 


CMS Storage Map 2. Storage Map 2 describes virtual storage usage when the 
user's virtual storage is larger than the CMS nucleus. The user may IPL 
by system name or device. In addition, this figure shows where there is 
insufficient room to place the system loader table above S-STAT and 
Y-STAT. (The arrows indicate that MAINHIGH is extended upward and 
FREELOWE is extended downward. ) 
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VIRTUAL STORAGE 


VM SIZE 
System Loader Table 
(Size determined by set LDRTBLS command) 


Storage Key = X‘F’ 


DMSFREE requests 


| -x'mB Storage Key = X‘E’ or X‘F’ fen 
NUCOMEGA rae 
S-STAT and Y-STAT =¢ 
(Shared — if IPL‘d by system name) ~ 
NUCSIGMA ie, 
CMS Nucleus wr) 
(Shared — if IPL’d by system name) oe. 
OS simulation, EXEC, EXEC 2, REXX, XEDIT, CMS bas 
interrupt handlers, file system, free storage management, = ES 
loader, device 1/O, debug. a 
we = x." 
X"MB - Storage Key = X’F’ or X‘0’ ¥ 
X‘70000’ if 


NUCALPHA DMSFREE requests when no more low storage is available 


Storage Key = X’E’ or X’F’ 


FREELOWE FPr----- e-e-eerorcrr ror 
Unused portion of User Program Area 
Storage Key = X’E’ CONTROL BLOCKS IN FREE STORAGE 
MAINHIGH Fe“ rrrerrrrrrrr rte 
Storage Key = X’E’ 
MAINSIRT FPPC CC CP er ee er er er eee i 
The User's Program ong 4 CMSSAVE CMSCB FSTB 
(Program is located via the LOAD command) : rr 
Storage Key = X‘E’ | . 
X'20000’ ’ 
Low Storage DMSFREE Nucleus Free Storage 
Area. The upper part of this area may contain the | 
S-STAT and/or the Y-STAT, followed by the 
FREETAB, if there is enough room. 
Storage Key = X’F’ [ 
X‘10000’ 
Transient Program Area 
Storage Key = X’E’ 
X’E0O00’ 
Low Storage DMSFREE User Free Storage Area 
Storage Key = X‘E’ 
X‘5000’ 
DMSNUC 
System Control Blocks, flags, constants, and pointers 
Storage Key = X’F’ * 
Xx’0' 


* The page starting at X’4000’ containing OPSECT, 
SUBSECT, DBGSECT, DMSERL, TSOBLKS, 
USERSECT, and free storage has a Storage Key = 
x’E’. 


Figure 6. CMS Storage Map 3. Storage Map 3 describes CMS virtual storage usage when 
the user's virtual storage is larger than the CMS nucleus. The user may 
IPL by system name or device. In addition, this figure shows where there 
is sufficient storage to place the system loader table above S-STAT and 
Y-STAT. (The arrows indicate that MAINHIGH is extended upward and 
FREELOWE is extended downward. ) 
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USERSECT (USER AREA) 
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DMSNUC is the portion of storage in a CMS virtual machine that 
contains system control blocks, flags, constants, and pointers. 


The CSECTs in DMSNUC contain only symbolic references. This 
means that an update or modification to CMS, which changes a 
CSECT in DMSNUC, does not automatically force all CMS modules to 
be recompiled. Only those modules that refer to the area that 
was redefined must be recompiled. 


The USERSECT CSECT defines space that is not used by CMS. A 
modification or update to CMS can use the 18 fullwords defined 
for USERSECT. There is a pointer (CAUSER) in the NUCON area to 
the user space. 


DEVTAB (DEVICE TABLE) 


The DEVTAB CSECT is a table describing the devices available for 
the CMS system. The table contains the following entries: 


1 console 


® 

° 26 disks 

e 1 reader 
e 1 punch 

e 1 printer 
e & tapes 


You can change some existing entries in DEVTAB. Each device 
table entry contains the following information: 


Virtual device address 

Device flags 

Device types 

Symbol device name 

Address of the interrupt processing routine (for the 
console) 


oe ee ee 


The virtual address of the console is defined at IPL time. The 
virtual address of the user disks can be altered dynamically 
with the ACCESS command. The virtual address of the tapes can 
be altered in the device table. Changing the virtual address of 
the reader, printer, or punch has no effect. 


CMS INTERFACE FOR DISPLAY TERMINALS 


CMS has an interface that allows it to display large amounts of 
data ina very rapid fashion. This interface for 3270 display 
terminals (also 3138, 3148, and 3158) is much faster and has 
less overhead than the normal write because it displays up to 
1760 characters in one operation, instead of issuing 22 
individual writes of 80 characters each (that is one write per 
line on a display terminal). Data that is displayed in the 
screen output area with this interface is not placed in the 
console spool file. 


The DISPW macro allows you to use this display terminal 
interface. It generates a calling sequence for the CMS display 
terminal interface module, DMSGIO. DMSGIO creates a channel 
program and issues a DIAGNOSE instruction (Code X‘'58'") to 
display the data. DMSGIO is a TEXT file that must be loaded to 
use DISPW. CIt is advisable for the user to save registers 
before issuing the DISPW macro and to restore them after the 
macro, because neither the macro nor its called modules save the 
user's registers. ) 
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The format of the CMS DISPW macro is: 


[label] 
bufad |,LINE=n »BYTES=bbbb 
, LINE=0 ,BYTES=1760 
C,ERASE-YES] [,CANCEL=YES] 


where: 


label 
is an optional macro statement label. 


bufad 
is the address of a buffer containing the data to be 
written to the display terminal. 


LINE=n 

LINE=0 
is the number of the line, 0 to 23, on the display terminal 
that is to be written. Line number 0 is the default. 


BYTES=1760 


is the number of bytes (0 to 1760) to be written on the 
display terminal. 1760 bytes is the default. 


eiteactens 


[ERASE=-YES] 
specifies that the display screen is to be erased before 
‘ the current data is written. The screen is erased ’ 
regardless of the line or number of bytes to be displayed. 4 
Specifying ERASE=YES causes the screen to go into "MORE" 
status. 
ECANCEL=YES] 


causes the CANCEL operation to be performed: the output 
area i8 erased. 
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When a language processor or a user-written program is executing 
in the CMS environment and using OS-type functions, it is not 
executing OS code. Instead, CMS provides routines that simulate 
the OS functions required to support OS language processors and 
their generated object code. 


CMS functionally simulates the OS macros in a way that presents 
equivalent results to programs executing under CMS. The OS 
macros are supported only to the extent stated in the 
publications for the supported language processors, and then 
only to the extent necessary to successfully satisfy the 
specific requirement of the supervisory function. 


Figure 7 on page 22 shows the OS macro functions that are 
partially or completely simulated, as defined by SVC number. 


os D A EMENT SIMULATION 


HANDLING FILES THAT 


HANDLING FILES THAT 


The disk format and data base organization of CMS are different 
from those of 0S. A CMS file produced by an OS program running 
under CMS and written on a CMS disk has a different format from 
that of an OS data set produced by the same OS program running 
under OS and written on an OS disk. The data is exactly the 
same, but its format is different. (An OS disk is formatted by 
an OS program, such as Device Support Facility.) 


RESIDE ON CMS DISKS 


CMS can read, write, or update any OS data that resides on a CMS 
disk. By simulating OS macros, CMS simulates the following 
access methods so that OS data organized by these access methods 
can reside on CMS disks: 


direct identifying a record by a key or by its relative 
position within the data set. 


partitioned seeking a named member within the data set. 


sequential accessing a record in a sequence in relation to 
preceding or following items in the data set. 


Refer to Figure 7 on page 22 and the "Simulation Notes,” then 
Sorts "Access Method Support™ to see how CMS handles these access 
methods. 


Since CMS does not simulate the indexed sequential access method 
CISAM), no OS program that uses ISAM can execute under CMS. 
Therefore, no program can write an indexed sequential data set 
on a CMS disk. 


RESIDE ON OS OR DOS DISKS 


By simulating OS macros, CMS can read, but not write or update, 
0S sequential and partitioned data sets that reside on OS disks. 
Using the same simulated OS macros, CMS can read DOS sequential 
files that reside on DOS disks. The OS macros handle the DOS 
data as if it were OS data. Thus, a DOS sequential file can be 
used as input to an OS program running under CMS. 


However, an OS sequential or partitioned data set that resides 
on an OS disk can be written or updated only by an OS program 
running in a real OS machine. 

CMS can execute programs that read and write VSAM files from OS 
programs written in the VS BASIC, COBOL, or PL/I programming 
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languages. This CMS support is based on the DOS/VSE Access 
Method Services and VSE/VSAM, and, therefore, the OS user is 
limited to those VSAM functions that are available under 


DOS/VSE. ) 


Macro SVC No. Function 

XDAP 00 Reads or writes direct access volumes 

WAIT 01 Waits for an I/0 completion 

POST 02 Posts the I/0 completion 

EXIT 03 Returns from a called phase 

RETURN 03 Returns from a called phase 

GETMAIN 04 Conditionally acquire user storage 

FREEMAIN 05 Releases user-acquired storage 

GETPOOL = Simulates as SVC 10 

FREEPOOL = Simulates as SVC 10 

LINK 06 Links control to another phase 

XCTL 07 eergeety then links control to another load 
phase 

LOAD 08 Reads a phase into storage 

DELETE 09 Deletes a loaded phase 

FREEMAIN 10 Manipulates user free storage 

GETMAIN 10 Manipulates user free storage 

TIME ll Gets the time of day 

ABEND 13 Terminates processing 

SPIE 14 Allow processing program to handle program 
interrupts 

RESTORE 17 Effective NOP 

BLDL 18 Builds a directory list for a partitioned 
data set 

FIND 18 Locates a member of a partitioned data set 

OPEN 19 Activates a data file 

CLOSE 20 Deactivates a data file 

STOW 21 Manipulates partitioned directories 

OPENJ 22 Activates a data file 

TCLOSE 23 Temporarily deactivates a data file 

DEVTYPE 24 Obtains device-type physical characteristics 

TRKBAL 25 Effective NOP 

FEOV 31 Sets forced EQV error code 

WTO/WTOR 35 Communicates with the terminal 

EXTRACT 40 Effective NOP 

IDENTIFY 41 Adds entry to loader table 

ATTACH 42 Effective LINK 

CHAP 44 Effective NOP 

TTIMER 46 Accesses or cancels timer 

STIMER 47 Sets timer interval and timer exit routine 

DEQ 48 Effective NOP 

SNAP 51 Dumps specified areas of storage 

EN@Q 56 Effective NOP 

FREEDBUF 57 Releases a free storage buffer 

STAE 60 Allows processing program to decipher abend 
conditions 

DETACH 62 Effective NOP 

CHKPT 63 Effective NOP 

RDJFCB 64 Obtains information from FILEDEF command 

SYNAD = Handles data set error conditions 

SYNADAF 638 Provides SYNAD analysis function 

SYNADRLS 68 Releases SYNADAF message and save areas 

BSP 69 Backs up a record ona tape or disk 

DCB = Constructs a data control block 

DCBD = Generates a DSECT for a data control block 

SAVE “= Saves program registers 

RETURN = Returns from a subroutine 

GET = Reads system~blocked data (QSAM) 

PUT = Writes system-blocked data (QSAM) 

READ = Accesses system-record data 

WRITE = Writes system-record data 

NOTE - Manages data set positioning 


Figure 7 (Part 1 of 2). Simulated OS Supervisor Calls 
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Macro SVC No. Function 

POINT = Manages data set positioning 
CHECK 7 Verifies READ/WRITE completion 
TGET/TPUT 93 Reads or writes a terminal line 
TCLEARQ 94 Clears terminal input queue 
STAX 96 Creates an attention exit block 
PGRLSE 112 Releases storage contents 


Figure 7 (Part 2 of 2). Simulated OS Supervisor Calls 


Because CMS has its own file system and is a single-user system 
operating ina virtual machine with virtual storage, there are 
certain restrictions for the simulated 0S function in CMS. For 
example, HIARCHY options and options that are used only by OS 
multitasking systems are ignored by CMS. 


Due to the design of the CMS loader, an XCTL from the explicitly 
loaded phase, followed by a LINK by succeeding phases, may cause 
unpredictable results. 


Listed below are descriptions of all the OS macro functions that 
are simulated by CMS as seen by the programmer. Implementation 
and program results that differ from those given in IBM 0S Data 
Management Macro Instructions and IBM 0S Supervisor Services and 
Macro Instructions are stated. HIARCHY options and those used 
only by OS multi-tasking systems are ignored by CMS. Validity 
checking is not performed within the simulation routines. The 
entry point name in LINK, XCTL, and LOAD (SVC 6, 7, 8) must be a 
member name or alias in a LOADLIB directory or ina TXTLIB 
directory unless the COMPSWT is set to on. If the COMPSWT is 
on, SVC 6, 7, and 8 must specify a module name. This switch is 
turned on and off by using the COMPSWT macro. See the VM/SP CMS 
Command and Macro Reference for descriptions of all CMS user 


macros. 


XDAP-SVC 0 
The TYPE option must be R or Ws; the V, I, and K options are 
not supported. The BLKREF-ADDR must point to an item 
number acquired by a NOTE macro. Other options associated 
with V, I, or K are not supported. 


WAIT-SVC 1 
All options of WAIT are supported. The WAIT routine waits 
for the completion bit to be set in the specified ECBs. 


POST-SVC 2 
All options of POST are supported. POST sets a completion 
code and a completion bit in the specified ECB. 


EXIT/RETURN-SVC 3 
Depending upon whether this is an exit or return from a 
linked or an attached routine, SVC 3 processing does the 
following: posts ECBs, executes end of task routines, 
releases phase storage, unchains and frees the latest 
request block, and restores registers. Do not use 
EXIT/RETURN to exit from an explicitly LOADed phase. If 
eee is used for this purpose, CMS issues abend code 


GETMAIN-SVC 4 
All options of GETMAIN are supported except SP, BNDRY=, 
HIARCHY, LC, and LV. SP, BNDRY=, and HIARCHY are ignored 
by CMS. LC and LV, result in abnormal termination if they 
are used. GETMAIN gets blocks of free storage. 
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FREEMAIN-SVC 5 
All options of FREEMAIN are supported except SP, which is 
ignored by CMS, and L, which results in abnormal 
termination if used. FREEMAIN frees blocks of storage 
acquired by GETMAIN. 


LINK-SVC 6 
The DCB and HIARCHY options are ignored by CMS. All other 
options of LINK are supported. LINK loads the specified 
program into storage Cif necessary) and passes control to 
the specified entry point. 


XCTL-SVC 7 
The DCB and HIARCHY options are ignored by CMS. All other 
options of XCTL are supported. XCTL loads the specified 
program into storage Cif necessary) and passes control to 
the specified entry point. 


LOAD-SVC 8 
The DCB and HIARCHY options are ignored by CMS. All other 
options of LOAD are supported. LOAD loads the specified 
program into storage Cif necessary) and returns the address 
of the specified entry point in register zero. If loading 
a subroutine is required when SVC 8 is issued, CMS searches 
directories for a TXTLIB member containing the entry point 
or for a TEXT file with a matching filename. An entry name 
in an unloaded TEXT file will not be found unless the 
filename matches the entry name. After the subroutine is 
loaded, CMS attempts to resolve external references within 
the subroutine, and may return another entry point address. 
To insure a correct address in register 0, the user should 
bring such subroutines into storage either by the CMS 
LOAD/INCLUDE commands or hy a VCON in the user program. 


GETPOOL/FREEPOOL 
All the options of GETPOOL and FREEPOOL are supported. 
GETPOOL constructs a buffer pool and stores the address of 
a buffer pool control block in the DCB. FREEPOOL frees a 
buffer pool constructed by GETPOOL. 


DELETE-SVC 9 
All the options of DELETE are supported. DELETE decreases 
the use count by one and, if the result is zero, frees the 
corresponding virtual storage. Code ¢ is returned in 
register 15 if the phase is not found. 


GETMAIN/FREEMAIN-SVC 10 
All the options of GETMAIN and FREEMAIN are supported 
except SP and HIARCHY, which are ignored by CMS. 


TIME-SVC ll 
CMS supports the DEC, BIN, TU, and MIC parameters of the 
TIME macro. TIME returns the time of day to the calling 
program. However, the time value that CMS returns is only 
accurate to the nearest second and is converted to the 
proper unit. 


ABEND-SVC 13 
The completion code parameter is supported. The DUMP 
parameter is not. If a STAE request is outstanding, 
control is given to the proper STAE routine. If a STAE 
routine is not outstanding, a message indicating that an 
abend has occurred is printed on the terminal along with 
the completion code. 


SPIE-SVC 14 
All the options of SPIE are supported. The SPIE routine 
specifies interruption exit routines and program 
een types that cause the exit routine to receive 
control. 


RESTORE-SVC 17 


The RESTORE routine in CMS is a NOP. It returns control to 
the user. 
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BLDL-SVC 18 
BLDL is an effective NOP for LINKLIBs and JOBLIBs. For 
TXTLIBS and MACLIBs, item numbers are filled in the TTR 
field of the BLDL list. The K, Z, and user data fields, as 
described in IBM OS/VS Data Management Macro Instructions, 
are set to zeros. The "alias" bit of the C field is 
supported, and the remaining bits in the C field are set to 
zero. 


FIND-SVC 18 
All the options of FIND are supported. FIND sets the 
read/write pointer to the item number of the specified 
member. 


STOW-SVC 21 
All the options of STOW are supported. The “alias” bit is 
supported, but the user data field is not stored in the 
Ooi directory since CMS MACLIBs do not contain user data 
ields. 


OPEN/OPENJ-SVC 19/22 
All the options of OPEN and OPENJ are supported except for 
the DISP, EXTEND, and RDBACK options, which are ignored. 
OPEN creates a CMSCB Cif necessary), completes the DCB, and 
merges necessary fields of the DCB and CMSCB. 


CLOSE/TCLOSE-SVC 20/723 
All the options of CLOSE and TCLOSE are supported except 
for the DISP option, which is ignored. The DCB is restored 
to its condition before OPEN. If the device type is disk, 
the file is closed. If the device type is tape, the REREAD 
option is treated as a REWIND. For TCLOSE, the REREAD 
option is REWIND, followed by a forward space file for 
tapes with standard labels. 


DEVTYPE-SVC 24 
With the exception of the RPS option, which CMS ignores, 
CMS accepts all options of the DEVTYPE macro instruction. 
In supporting this macro instruction, CMS groups all 
devices of a particular type into the same class. For 
example, all printers are grouped into the printer class; 
all tape drives into the tape drive class, and so forth. 
In response to the DEVTYPE macro instruction, CMS provides 
the same device characteristics for all devices ina 
particular class. Thus, all devices in a particular class 
appear to be the same device type. 


The device type characteristics CMS returns for each class 


are: 
Device 
Class Characteristics 
Printer 1403 
Card reader 2540 
Console 1052 
Tape drive 2400 (9 track) 
DASD 2314 
Card punch 2540 
DUMMY 2314 
unassigned 2314 


FEOV-SVC 31 
Control is returned to CMS with an error code of 4 in 
register 15. 


WTO/WTOR-SVC 35 
All options of WTO and WTOR are supported except those 
options concerned with multiple console support. WTO 
displays a message at the operator's console. WTOR 
displays a message at the operator's console, waits for a 
reply, moves the reply to the specified area, sets a 
completion bit in the specified ECB, and returns. There is 
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no check made to determine if the operator provides a reply 
that is too long. The reply length parameter of the WTOR 
macro tnstruction specifies the maximum length of the 
Selgin The WTOR macro instruction reads only this amount 
of data. 


EXTRACT-SVC 40 
The EXTRACT routine in CMS is essentially a NOP. The 
user-provided answer area is set to zeros and control is 


returned to the user with a return code of 4 in register 
15% 


IDENTIFY-SVC 41 
The IDENTIFY routine in CMS adds a REQUEST block to the 
load request chain for the requested name and address. 


ATTACH-SVC 42 

All the options of ATTACH are supported in CMS as in OS 
PCP. The following options are ignored by CMS: DCB, LPMOD, 
DPMOD, HIARCHY, GSPV, GSPL, SHSPV, SHSPL, SZERO, PURGE, 
ASYNCH, and TASKLIB. ATTACH passes control to the routine 
specified, fills in an ECB completion bit if an ECB is 
specified, passes control to an exit routine if one is 
specified, and returns control to the instruction following 
the ATTACH. 


Since CMS is not a multi-tasking system, a phase requested 
by the ATTACH macro must return to CMS. 


CHAP-SVC 44 
The CHAP routine in CMS is a NOP. It returns control to 
the user. 


TTIMER-SVC 46 
All the options of TTIMER are supported. 


STIMER-SVC 47 
All options of STIMER are supported except for TASK and 
WAIT. The TASK option is treated as if the REAL option had 
been specified, and the WAIT option is treated as a NOP; it 
returns control to the user. The maximum time interval 
allowed is X*7FFFFFO0O* timer units €X'00555554' in binary, 
or 15 hours, 32 minutes, and 4 seconds in decimal). If the 
time interval is greater than the maximum, it is set to the 
maximum. IKIf running in the CMSBATCH environment, issuing 
the STIMER or TTIMER macro will affect the CMSBATCH time 
limit. Depending on the frequency, number, and duration of 
STIMER and/or TTIMER issued, the CMSBATCH time limit may 
never expire. 


DEQ-SVC 48 
The DEQ routine in CMS is a NOP. It returns control to the 
user. 

SNAP-SVC 51 


Except for SDATA, PDATA, and DCB, all options of the SNAP 
macro are processed normally. SDATA and PDATA are ignored. 
Processing for the DCB option is as follows. The DBC 
address specified with SNAP is used to verify that the file 
associated with the DCB is open. If it is not open, 
control is returned to the caller with a return code of 4. 
If the file is open, then storage is dumped Cunless the FCB 
indicates a DUMMY device type). SNAP always dumps output 
to the printer. The dump contains the PSW, the registers, 
and the storage specified. 


EN@-SVC 56 
The EN@ routine in CMS is a NOP. It returns control to the 
user. 


FREEDBUF-SVC 57 
All the options of FREEDBUF are supported. FREEDBUF 
returns a buffer to the buffer pool assigned to the 
specified DCB. 
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STAE-SVC 60 
All the options of STAE are supperted except for the XCTL 
option, which is set to XCTL=YES; the PURGE option, which 
is set to HALT; and the ASYNCH option, which is set to NO. 
STAE creates, overlays, or cancels a STAE control block as 
requested. STAE retry is not supported. 


DETACH-SVC 62 
The DETACH routine in CMS is a NOP. It returns control to 
the user. 


CHKPT-SVC 63 


The CHKPT routine is a NOP. It returns control to the 
user. 


RDJFCB-SVC 64 
All the options of RDJFCB are supported. RDJFCB causes a 
Job File Control Block (JFCB) to be read from a CMS Control 
Block CCMSCB) into real storage for each data control block 
specified. FILEDEF commands create CMSCBs. 


nor additional information, see section "0S Simulation by 
cms.” 


SYNADAF-SVC 68 
All the options of SYNADAF are supported. SYNADAF analyzes 
an I/0 error and creates an error message in a work buffer. 


SYNADRLS-SVC 68 
All the options of SYNADRLS are supported. SYNADRLS frees 
the work area acquired by SYNAD and deletes the work area 
from the save area chain. 


BSP-SVC 69 
All the options of BSP are supported. BSP decrements the 
item pointer by one block. 


TGET/TPUT-SVC 93 
TGET and TPUT operate as if EDIT and WAIT were coded. TGET 
reads a terminal line. TPUT writes a terminal line. 


TCLEARQ-SVC 94 
TCLEARQ in CMS clears the input terminal queue and returns 
control to the user. 


STAX-SVC 96 
The only option of the STAX that is supported is EXIT 
ADDRESS. Updates a queue of CMTAXESsS each of which defines 
an attention exit level. 


PGRLSE-SVC 112 
Release all complete pages (4K bytes) associated with the 
area of storage specified. 


All the options of NOTE are supported. NOTE returns the 
item number of the last block read or written. 


POINT 
All the options of POINT are supported. POINT causes the 
control program to start processing the next read or write 
operation at the specified item number. The TTR field in 
the block address is used as an item number. 


CHECK 
All the options of CHECK are supported. CHECK tests the 
I/0 operation for errors and exceptional conditions. 


DCB 
The following fields of a DCB may be specified relative to 
the particular access method indicated: 
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ACCESS METHOD SUPPORT 


An access method governs the manipulation of data. To facilate 
the execution of OS code under CMS, the processing program must 
see data as OS would present it. For instance, when the 
processors expect an access method to acquire input source cards 
sequentially, CMS invokes specially written routines that 
simulate the 0S sequential access method and pass data to the 
processors in the format that the 0S access methods would have 
produced. Therefore, data appears in storage as if it had been 
manipulated using an OS access method. For example, block 
descriptor words (BDW), buffer pool management, and variable 
records are updated in storage as if an OS access method had 
processed the data. The actual writing to and reading from the 
I/0 device is handled by CMS file management. Note that the 
character string X'61FFFF61' is interpreted by CMS as an end of 
file indicator. 


The essential work of the volume table of contents (CVTOC) and 
the data set control block (CDSCB) is done in CMS by a master 
file directory (MFD), which updates the disk contents, and a 
file status table (FST) Cone for each data file). All disks are 
formatted in physical blocks of 512, 800, 1K, 2K, or 4K bytes. 


CMS continues to update the OS format, within its own format, on 
the auxiliary device for files whose filemode number is 4. That 
is, the block and record descriptor words (BDW and RDW) are 
written along with the data. If a data set consists of blocked 
records, the data is written to and read from the I/0 device in 
physical blocks rather than logical records. CMS also simulates 
the specific methods of manipulating data sets. 


To accomplish this simulation, CMS supports certain essential 
macros for the following access methods: 


BDAM (direct) -- identifying a record by a key or by its 
relative position within the data set. 

BPAM Cpartitioned) ~- seeking a named member within data 
set. 

BSAM/QSAM (Csequential) -- accessing a record in a sequence in 


relation to preceding or following records. 


1 If an input data set is not a BDAM data set, zero is the 
only value that should be specified for KEYLEN. This 
applies to the user exit lists as well as to the DCB macro 
instruction. 
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VSAM Cdirect or sequential) -- accessing a record 
sequentially or directly by key or address. 


Note: CMS support of OS VSAM files is based on 
VSE/VSAM. See "CMS Support for OS and DOS VSE/VSAM 
Functions” under "VSE Support Under CMS" for details. 


CMS also updates those portions of the OS control blocks that 
are needed by the OS simulation routines to support a program 
during execution. Most of the simulated supervisory OS control 
blocks are contained in the following two CMS control blocks: 


CMSCVT simulates the communication vector table. Location 16 
contains the address of the CVT control section. 


CMSCB is allocated from system free storage whenever a FILEDEF 
command or an OPEN (SVC 19) is issued for a data set. 
The CMS Control Block consists of a file control block 
CFCB) for the data file and partial simulation of the 
job file control block (JFCB), input/output block CIOB), 
and data extent block (DEB). 


The data control block (DCB) and the data event control block 
(DECB) are used by the access method simulation routines of CMS. 


Note: The results may be unpredictable if two DCBs access the 
same data set at the same time. 


The GET and PUT macros are not supported for use with spanned 
records, except in GET locate mode. READ, WRITE and GET Cin 
locate mode) are supported for spanned records, provided the 
ore number is 4, and the data set is in physical sequential 
ormat. 


GET (Q@SAM) 
All the QSAM options of GET are supported. Substitute mode 
is handled the same as move mode. For CMS files, when the 
DCBRECFM is FB, the filemode number is 4, the last block is 
a short block, and an EOF indicator (CX'61FFFF61') must be 
present in the last block after the last record. 


GET CQISAM) 
QISAM is not supported in CMS. 


PUT C€Q@SAM) 
All the QSAM options of PUT are supported. Substitute mode 
is handled the same as move mode. If the DCBRECFM is FB, 
the filemode number is 4, and the last block is a short 
block. An EOF indicator is written in the last block after 
the last record. 


PUT CQISAM) 
QISAM is not supported in CMS. 


PUTX 
PUTX support is provided only for data sets opened for 
QSAM-UPDATE with simple buffering. 


READ/WRITE CBISAM) 
BISAM is not supported in CMS. 


READ/WRITE CBSAM and BPAM) 
All the BSAM and BPAM options of READ and WRITE are 
supported except for the SE option Cread backwards). 


READ (Offset Read of Keyed BDAM dataset) 
This type of READ is not supported because it is used only 
for spanned records. 


READ/WRITE CBDAM) 


All the BDAM and BSAM (create) options of READ and WRITE 
are supported except for the R and RU options. 
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BDAM Restrictions 


When an input or output error occurs, do not depend on OS sense 
bytes. An error code is supplied by CMS in the ECB in place of 
the sense bytes. These error codes differ for various types of 
devices and their meaning can be found in the VM/SP System 
Messages and Codes, under DMS message 1205S. 


Note: If OPTCD J is specified in the FILEDEF command, the 
proper flag is set in the JFCOPTCD byte of the FCBSECT 
(simulated 0S control block). During simulation of the OS OPEN 
macro, the FILEDEF value will be merged into DCBOPTCD. After 
DCBOPTCD is set, the first data byte of output lines presented 
to the PUT (QSAM) and WRITE (BSAM) macros is interpreted as a 
table reference character (TRC) byte. CP uses the TRC byte to 
select translate tables when printing on a 3800. The translate 
table determines the font type at real print time. If the 
virtual printer is not a 3800, the TRC byte is stripped off and 
the line is printed in the usual manner. 


The four methods of accessing BDAM records are: 


1. Relative Block RRR 

2. Relative Track IIR 

3. Relative Track and Key TTKey 
4. Actual Address MBBCCHHR 


The restrictions on these access methods are as follows: 
e Only the BDAM identifiers underlined above can be used to 


refer to records, since the CMS simulation of BDAM files 
uses a three-byte record identifier on 512, 1K, 2K, and 4K 


format CMS minidisks. For 800-byte disks, only the last two 


identifiers are used. 


e CMS BDAM files are always created with 255 records on the 
first logical track, and 256 records on all other logical 


tracks, regardless of the block size. If BDAM methods 2, 3, 


or 4 are used and the RECFM is U or V, the BDAM user must 
either write 255 records on the first track and 256 records 


on every track thereafter, or they must not update the track 


indicator until a NO SPACE FOUND message is returned on a 
write. For method 3 (WRITE ADD), this message occurs when 
no more dummy records can be found on a WRITE request. For 
methods 2 and 4, this does not occur, and the track 
indicator is updated only when the record indicator reaches 
256 and overflows into the track indicator. 


e Two files of the same filetype, which use keys, cannot be 
open at the same time. If a program that is updating keys 
does not close the file it is updating, for example because 
of a system failure or another IPL operation, the original 
keys for files that are not fixed format are saved in a 
temporary file with the same filetype and a filename of 
SKEYSAVE. To finish the update, run the program again. 


e Once a file is created using keys, additions to the file 
must not be made without using keys and specifying the 
original length. 


e The number of records in the data set extent must be 


specified using the FILEDEF command. The default size is 50 


records. 


° The minimum LRECL for a CMS BDAM file with keys is eight 
bytes. 
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READING OS DATA SETS AND DOS FILES USING OS MACROS 


| CMS users can read 0S sequential and partitioned data sets that 
reside on OS disks. The CMS MOVEFILE command can be used to 
manipulate those data sets, and the OS QSAM, BPAM, and BSAM 
macros can be executed under CMS to read them. 


The CMS MOVEFILE command and the same OS macros can also be used 
to manipulate and read DOS sequential files that reside on DOS 
disks. The OS macros handle the DOS data as if it were OS data. 


The following OS Release 20.0 BSAM, BPAM, and QSAM macros can be 
used with CMS to read OS data sets and DOS files: 


BLDL EN@ RDJFCB 
BSP FIND READ 
CHECK GET SYNADAF 
CLOSE NOTE SYNADRLS 
DEQ POINT WAIT 


DEVTYPE POST 


CMS supports the following disk formats for the OS and OS/VS 
sequential and partitioned access methods: 


Split cylinders 
User labels 
Track overflow 
Alternate tracks 


As in OS, the CMS support of the BSP macro produces a return 
code of 4 when attempting to backspace over a tape mark or when 
a beginning of an extent is found on an OS data set or a VSE 
file. If the data set or data file contains split cylinders, an 
attempt to backspace within an extent, resulting in a cylinder 
switch, also produces a return code of 4¢. 


. = The ACCESS Command 
Before CMS can read an OS data set or VSE file that resides ona 
non-CMS disk, you must issue the CMS ACCESS command to make the 
disk available to CMS. 


The format of the ACCESS command is: 


ACCESS cuu model[/ext] 


You must not specify options or file identification when 
accessing an OS or DQS disk. 


The FILEDEF Command 
You then issue the FILEDEF command to assign a CMS file 


identification to the OS data set or VSE file so that CMS can 
read it. 
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The format of the FILEDEF command used for this purpose is: 


FIledef 


DISK |fn ft fm 
FILE ddname {Al 


or 


{ ddname 


nn 
% DISK fn ft fm DSN ? 
FILE ddname Al DSN quall qual2 ... \ 


DSN quall.qual2 


DUMMY 


Related Option: 


MEMBER membername 
CONCAT 


If you are issuing a FILEDEF for a VSE file, note that the 05 
program that will use the VSE file must have a DCB for it. For 
"ddname™ in the FILEDEF command line, use the ddname in that 
DCB. With the DSN operand, enter the fileid of the VSE file. 


Sometimes, CMS issues the FILEDEF command for you. Although the 

CMS MOVEFILE command, the supported CMS program product 

interfaces, and the CMS OPEN routine each issue a default 

FILEDEF, you should issue the FILEDEF command yourself to ensure J 
the appropriate file is defined. 


After you have issued the ACCESS and FILEDEF commands for an 05S 
sequential data set, 05 partitioned data set, or VSE sequential 
file, CMS commands (such as ASSEMBLE and STATE) can refer to the 
OS data set or VSE file just as if it were a CMS file. 


Several other CMS commands can be used with OS data sets and DOS 
files that do not reside on CMS disks. See the VM/SP CMS Command 
and Macro Reference for a complete description of the CMS 
ACCESS, FILEDEF, LISTDS, LKED, MOVEFILE, OSRUN, QUERY, RELEASE, 
and STATE commands. 


For restrictions on reading 0S data sets and DOS files under 
CMS, see the VM/SP Planning Guide and Reference. 

The CMS FILEDEF command allows you to specify the I/0 device and 
the file characteristics to be used by a program at execution 


time. In conjunction with the OS simulation scheme, FILEDEF 
simulates the functions of the data definition JCL statement. 


FILEDEF may be used only with programs using OS macros and 
functions. For example: 


filedef filel disk proga data al 


After issuing this command, your program referring to FILEl 
would access PROGA DATA on your A-disk. 


If you wished to supply data from your terminal for FILE1, you 
could issue the command: 


filedef filel terminal ) 
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and enter the data for your program without recompiling. 
fi tapein tap2 (Crecfm fb lrecl 50 block 100 9track den 800) 


After issuing this command, programs referring to TAPEIN 
accesses a tape at virtual address 182. (Each tape unit in the 
CMS environment has a symbolic name associated with it.) The 
tape must have been previously attached to the virtual machine 
by the VM/SP operator. 


THE AUXPROC OPTION OF THE FILEDEF COMMAND: The AUXPROC option 
can only be used by a program call to FILEDEF and not from the 
terminal. The CMS language interface programs use this feature 
for special I/0 handling of certain Cutility) data sets. 


The AUXPROC option, followed by a fullword address of an 
auxiliary processing routine, allows that routine to receive 
control from DMSSEB before any device I/0 is performed. At the 
completion of its processing, the auxiliary routine returns 
control to DMSSEB signaling whether or not I/0 has been 
performed. If it has not been done, DMSSEB performs the 
appropriate device I/O. 


When control is received from DMSSEB, the general-purpose 
registers contain the following information: 


GPR2 = Data Control Block (DCB) address 
GPR3 = Base register for DMSSEB 

GPR& = CMS OPSECT address 

GPR11 = File Control Block (FCB) address 
GPR14 = Return address in DMSSEB 

GPRI5 = Auxiliary processing routine address 


all other registers Work registers 

The auxiliary processing routine must provide a save area to 
save the general registers; this routine must also perform the 
save operation. DMSSEB does not provide the address of a save 
area in general register 13, as is usually the case. When 
control returns to DMSSEB, the general registers must be 
restored to their original values. Control is returned to 
ela by branching to the address contained in general register 


GPR15 is used by the auxiliary processing routine to inform to 
DMSSEB of the action that has been or should be taken with the 
data block as follows: 


Register Action 


GPR15=0 No I/0 performed by AUXPROC routine; DMSSEB 
Will perform I/0. 

GPR15<0 I/0 performed by AUXPROC routine and error was 
encountered. DMSSEB will take error action. 

GPR15>0 I/0 performed by AUXPROC routine with residual 
count in GPR15; DMSSEB returns normally. 

GPR15=64K 1/0 performed by AUXPROC routine with zero 
residual count. 
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CMS supports interactive program development for VSE. This 
includes creating, compiling, testing, debugging, and executing 
commercial application programs. The VSE programs can be 
executed in a CMS virtual machine or ina CMS Batch Facility 
virtual machine. 


VSE files and libraries can be read under CMS. VSAM data sets 
can be read and written under CMS. 


The CMS VSE environment (called CMS/DOS) provides many of the 
same facilities that are available in VSE. However, CMS/DOS 
supports only those facilities that are supported by a single 
(background) partition. The VSE facilities provided by CMS/DOS 
are: 


VSE linkage editor 

Fetch support 

VSE Supervisor and I/0 macros 

VSE Supervisor control block support 
Transient area support 

VSE/VSAM macros 


This environment is entered each time the CMS SET DOS ON command 
is issued; VSAM functions are available in CMS/DOS only if the 
SET DOS ON CVSAM) command is issued. In the CMS/DOS 
environment, CMS supports many VSE facilities, but does not 
support OS simulation. When you no longer need VSE support 
under CMS, you issue the SET DOS OFF command and VSE facilities 
are no longer available. 


CMS/DOS can execute programs that use the sequential access 
method (SAM) and VSE/VSAM and can access VSE libraries. 


CMS/DOS cannot execute programs that have execution-time 
restrictions, such as programs that use sort exits, 
teleprocessing access methods, or multitasking. DOS/VS COBOL, 
DOS PL/I, DOS/VS RPG II and Assembler language programs are 
executable under CMS/DOS. 


All of the CP and CMS online debugging and testing facilities 
Csuch as the CP ADSTOP and STORE commands and the CMS DEBUG 
environment) are supported in the CMS/DOS environment. Also, CP 
disk error recording and recovery is supported in CMS/DOS. 


With its support of a CMS/DOS environment, CMS becomes an 
important tool for VSE application program development. Because 
CMS/DOS is a VSE program development tool, it assumes that a VSE 
system exists, and uses it. The following sections describe 
what is supported and what is not. 


| CMS SUPPORT FOR OS AND VSE VSAM FUNCTIONS 


CMS supports interactive program development for OS and VSE 
programs using VSE/VSAM. CMS supports VSAM macros for OS and 
VSE programs. The complete set of VSE/VSAM macros and options 
and a subset of OS/VSAM macros are supported for execution with 
Assembler language programs. 


CMS also supports Access Method Services to manipulate OS and 
¥VSE VSAM and SAM data sets. 


Under CMS, VSAM data sets can span up to 10 DASD volumes. CMS 
does not support VSAM data set sharing. However, CMS already 

supports the sharing of minidisks or full pack minidisks. 

VSAM data sets created in CMS are not in the CMS file format. 

Therefore, CMS commands currently used to manipulate CMS files 
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cannot be used for VSAM data sets that are read or written in 


CMS. 


A VSAM data set created in CMS has a file format that is 
compatible with OS and DOS VSAM data sets. 
set created in CMS can later be read or updated by OS or DOS. 


Thus, a VSAM data 


This compatibility with OS is limited to VSAM data sets created 


[ with physical record sizes of 512, 


1K, 2K, and 4K bytes. For 


further information on compatibility between OS/VS VSAM and 
VSE/VSAM, please refer to the IBM VSE/VSAM General Information 


Manual. 


Because VSAM data sets in CMS are not a part of the CMS file 


system, 


CMS file size, 


restrictions do not apply. 
With Access Method Services programs executed under CMS instead 


of with the CMS file system commands. 


record length, and minidisk size 


The VSAM data sets are manipulated 
Also, all VSAM minidisks 


| and full packs used in CMS must be initialized by the Device 


Support Facility (DSF); 


the CMS FORMAT command must not be used. 


CMS supports VSAM control blocks with the GENCB, MODCB, TESTCB, 
and SHOWCB macros. 


In its support of VSAM data sets, 
position sensing) wherever possible. 


CMS uses RPS Crotational 
CMS does not use RPS for 


2314/2319 devices or for 3340 devices that do not have the 


feature. 


HARDWARE DEVICES SUPPORTED 


[ CMS support of VSAM data sets is based on VSE/VSAM. 


Except for 


the 3380, only disks supported by VSE can be used for VSAM data 
These disks are: 


sets in CMS. 
e IBM 2314 


° IBM 2319 
e IBM 3310 
e IBM 3330 
° IBM 3330 
° IBM 3340 
e IBM 3344 
e IBM 3350 
e IBM 3370 
@ IBM 3375 
| ° IBM 3380 
only) 


Direct Access Storage Facility 


Disk Storage 


Direct 


Access 


Disk Storage, 


Disk Storage, 


Direct 
Direct 
Direct 
Direct 
Direct 


Direct 


CMS disk files used 
Services may reside 


Access 
Access 
Access 
Access 
Access 


Access 


Storage 

Models 1 and 2 

Model 11 

Storage Facility 

Storage 

Storage 

Storage 

Storage 

Storage COS/VSAM environment of CMS 


as input to or output from Access Method 


on any 


disk supported by CMS. 
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SECTION 2: CMS METHOD OF OPERATION AND PROGRAM ORGANIZATION 


This section contains the following information: 

6 Initialization of the CMS Virtual Machine Environment 

® Processing and Executing CMS Files 

e Processing Commands that Manipulate the File System 

6 Managing the CMS File System 

e Handling I/O Operations 

e Handling Interruptions 

e Managing CMS Storage 

° Simulating Non-CMS Operating Environments 

e Performing Miscellaneous CMS Functions 

The CMS description is in two parts. The first part contains 
figures showing the functional organization of CMS. The second 
part contains general information about the internal structure 
of CMS programs and their interaction with one another. 

CMS program organization is in two figures. Figure 8 on page 38 
is an overview of the functional areas of CMS. Each block is 


numbered and corresponds to a more detailed outline of the 
function found in Figure 9 on page 33 
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Figure 8. An Overview of the Functional Areas of CMS 
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Figure 9 (Part 1 of 5). 
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There are four steps involved in initializing a CMS virtual 
machine: 


e Processing the IPL command for a virtual card reader. 


e Processing the IPL command for a disk device or a named or 
saved system. 


e Processing the first command line entered at the CMS virtual 
console. 


e Setting up the options for the virtual machine operating 
environment. 


DMSINI and DMSINS are the two routines that are mainly 
responsible for the one-time initialization process in which the 
virtual card reader is initial program loaded. DMSINI also 
handles the IPL process when a named or saved system is loaded. 
The CMS command interpreter, DMSINT, processes the first line 
entered from the console as a special case; the processing 
performed by this code is a part of the initialization process. 
DMSSET sets up the user-specified virtual machine environment 
dy ila DMSQRY allows the user to query the status of these 
settings. 


T ZATION: ADING A CMS VIRTUAL MACHINE FROM CARD READ 


INITIALIZES STORAGE 


When a virtual card reader is specified by the IPL command, for 
example 00C, initialization processing begins. Initialization 
refers to the process of loading from a card reader as opposed 
to reading a nucleus from a cylinder of a CMS minidisk or 
reading a named or shared system (description follows). 


IPL 00C invokes the CMS module DMSINI, which requests that the 
operator enter information such as tha address of the DASD where 
the nucleus is to be written, the cylinder address where the 
write operation is to begin, and the version of CMS that is to 
be written Cif there is more than one to choose from). 


When all questions are answered, the requested nucleus is 
written to the DASD 


Once written on the DASD, a copy of the nucleus is read into 
virtual machine storage. One track at a time is read from the 
disk-resident nucleus into virtual storage. DMSINS is then 
invoked to initialize storage constants and to set up the disks 
and storage space required by this virtual machine. 

DMSINS performs three general functions: 

e Initializes storage constants and system tables. 


e Processes IPL command line parameters (BATCH and AUTOCR). 


CONTENTS AND SYSTEM TABLES 


DMSINS 
Saves the address of this virtual machine in NUCON. 


DMSLAD 
Locates and returns the address of the ADT for this virtual 
machine. 


DMSFRE 
Allocates free storage to be used during initialization. 
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Allocates all low free nucleus storage so the system status. 


table (SSTAT) can be built in high free storage. 


DMSACM 
Reads the S-disk ADT entry and builds the SSTAT. Reads the 
Y-disk ADT entry and builds the YSTAT. 


DMSFRE 
Releases the low nucleus free storage allocated above (to 
force SSTAT into high storage) so it can be used again. 


DMSINS 
acon. the address of SSTAT into ASSTAT and ADTFDA in 


DMSALU 
Sorts the entries in the SSTAT and YSTAT. 


PROCESSES IPL COMMAND LINE PARAMETERS 


DMSINS 
Checks for parameters BATCH or AUTOCR. If BATCH is 
specified, DMSINS sets the flag BATFLAGS. At this point, 
all the parameters on the command line have been scanned. 


If AUTOCR is specified, a local flag is set so that the 
subsequent console read may be bypassed and the null line 
eee This action causes a PROFILE EXEC to be 
executed. 


DMSINS 
Issues DIAGNOSE 24 to obtain the device type of the 
console. 


DMSCHR 
Writes the system id message to the console. 


DMSCRD 
Reads the IPL command line from the console. 


DMSSCN 
Puts the IPL command line in PLIST format. 


DMSINS 
If BATCH is specified, sets BATFLAGS and BATFLAG2 in NUCON. 
net the name of the BATCH saved system in SYSNAME in 
N a 


DMSACC 
rete ACCESS 195 A to access the batch virtual machine 
~disk. 


DMSINS 
Issues DIAGNOSE 60 to get the size of the virtual machine 
and sets up enough storage for this virtual machine. Sets 
the FREELOWE pointer in NUCON. 


DMSINS 
Performs time-of-day processing and 05 initialization. 


A validity check is performed when a saved system is IPLed 
to ensure that the saved copy of the S-STAT or Y-STAT is 
current. This check is performed only for S-disks and 
Y-disks formatted in 512-, 1024-, 2048-, or 4096-byte CMS 
blocks. For 800-byte block disks, the saved copy of the 
S-STAT or Y-STAT is used. 


A validity check consists of comparing the date that the 


saved directory was last updated with the date that the 
current disk was last updated. If the dates for thea S~-STAT 


46 VM/SP System Logic and Problem Determination Guide (CMS) 


J 


Licensed Material~-Property of IBM 


are different, the S-STAT is built in user storage. If the 
dates for the Y-STAT are different, the Y-disk is accessed 
using the CMS ACCESS command: 


ACCESS 19E Y/S * *® Y2 (1) 


This means that even when the S- and Y-disks are accessed 
in read/write mode and then released, the message 
DMSINSLOOW S-STAT and/or Y-STAT not available will result. 


e The DASD address of the Y-disk is whatever was 
specified when CMS was generated. For the standard 
system, 1t is 19E. 


' INITIALIZE OS SVC-HANDLING 


DMSINS 
If the BATCH virtual machine is not being loaded, 
determines whether there is a PROFILE EXEC or a first 
command line to be handled. If so, issues SVC 202's to 
process these commands and passes control to DMSINT, the 
CMS console manager. 


DMSACC 
If the BATCH virtual machine is being initial program 
loaded, it accesses the D-disk and passes control to 
DMSINT, the console manager. 


MED O VED S$ EM 


The CMS system is designed to be used as a saved, shared system. 
A named system is a copy of the nucleus that has been saved and 
named with the CP SAVESYS command. It is faster to IPL a named 
system than to IPL by disk address because CP maintains the 
named system in page format instead of CMS disk format. The 
initialization of a saved system is also faster because the 
SSTAT and YSTAT are already built. 


The shared system is a variant of the saved system. In the 
shared system, reentrant portions of the nucleus are placed in 
storage pages that are available to all users of the shared 
system. Each user has his own copy of nonreentrant portions of 
the nucleus. The shared pages are protected by CP and may not 
be altered by any virtual machine. 


During DMSINI processing, the virtual machine operator is asked 
if the nucleus must be written (via message DMSINI607R). If the 
operator answers no, control passes directly to DMSINS to 
initialize the named or saved system specified by the operator 
in his answer to message DMSINI606R. 


MODIFYING A 3800 NAMED SYSTEM 


The IMAGEMOD command allows an installation to modify an 
existing 3800 named system without the need for generating from 
scratch a completely new one. Before, with the IMAGELIB 
command, a user had to construct a 3800 named system from a 
control file that listed all the members to be included. The 
IMAGELIB command contained no means for modifying an existing 
3800 named system. Therefore, a system with, for example, 150 
members, had to be totally reconstructed each time a member was 
added, deleted, or replaced. The IMAGEMOD command eliminates 
this problem by manipulating only the specific members of a 3800 
named system that require changing. 
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The format of the IMAGEMOD command is: 


{GEN|ADD|REP|DEI|MAP} 
libname 


modname [modname]... 
CLTERM|PRINT|DISK] 


For further information, 


refer to the VM/SP Operator's Guide. 


Processing the IMAGEMOD Command 


Module DMSIMA performs the following steps when processing the 
IMAGEMOD command: 


L. 
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Analyze the input PLIST for syntax. If there is an error, 
exit with a return code of 2 and issue the appropriate 
message: 


° DMSIMAOD01LE = NO MODULE NAME SPECIFIED 

e DMSIMAOO3E = INVALID OPTION ‘option’ 

° DMSIMAO14E = INVALID FUNCTION ‘function’ 
° DMSIMAO46E = NO LIBRARY NAME SPECIFIED 

e DMSIMA047E = NO FUNCTION SPECIFIED 


Obtain maximum storage area (via GETMAIN macro). 

Unless the GEN function is specified, read the named system 
into storage just obtained with DIAGNOSE code X'74'. Leave 
the first 10 pages of storage empty. This permits later 
expansion by 10 members. 


Determine the type of function requested: 


eeeee 
@ 
m 
z 


If the function requested is MAP, scan the named system 
eure ory and format the following information about each 
member : 


e Name 
° Relative displacement 
® Total size 


Determine the option requested. If the option is TERM, 
PRINT, or DISK; place the formatted information on the 
user's terminal, virtual printer, or in the CMS file named 
"‘libname MAP A5‘, respectively. 


If the function requested is DEL, delete the member from the 
directory and the data area of the named system. Compress 
the named system by moving up the remaining members to take 
up the space vacated by the deletion. If the member is not 
found, issue message DMSIMAO01L3E. 


If the function requested is GEN, construct a skeleton named 
system in virtual storage. This skeleton system has no 
members initially. Then proceed as if the function were 
ADD. 


If the function requested is ADD, 
CMS transient area. 
DMSIMA346E and exit 
member entry to the 
virtual capacity is 
DMSIMALOQE and exit 


load the member into the 
If a load error occurs, issue 

with return code of 6. Add the new 

end of the named system directory. If 

exceeded by this addition, issue 

with return code of 2. During this 
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process, the directory is moved back in storage one page to 
prevent new data from overlaying existing data. Move the 
new member data to the end of the named system residing in 
user virtual storage. Modify the directory entries after 
this move takes place. If the member already exists, issue 
message DMSIMA751E and exit with return code of 4. 


9. If the function requested is REP, concatenate the DEL and 
ADD functions. In other words, perform the DEL function and 
then the ADD function for the specified member. 


10. Scan the input command line for more members to be 
processed. If there are no more members or if the number of 
members has reached the maximum (10), write the changed 
named system back to disk via DIAGNOSE code X'74' Cunless 
this was a MAP function request) and then exit. Otherwise, 
process the next member according to the function requested. 


HANDLING THE FIRST COMMAND LINE PASSED TO CMS 


DMSINT, the CMS console manager, contains the code to handle 
commands stacked by module DMSINS during initialization 
processing. DMSINT checks for the presence of a stacked command 
line, and if there is one to process, DMSINT processes it just 
as 1t would a command entered during a terminal session. That 
is» DMSINT calls the WAITREAD subroutine and issues an SYC 202 
to execute the command. When first command processing 
completes, DMSINT receives control to handle commands entered at 
the console for the duration of the session. 


SETTING THE VIRTUAL MACHINE ENVIRONMENT OPTIONS 


DMSSET sets up the virtual machine environment options, as 
outlined in the publication VM/SP_ CMS Command and Macro 
Reference. This module is structured and relatively easy to 
follow, except for some sections of DMSSET. 


DMSSET: SET DOS ON (VSAM) PROCESSING 


DMSSET 
(label DOS) If a disk mode is specified on the command 
line, ensures that it is valid. 


DMSLAD 
If the disk mode specified is valid, locates and returns 
the address of the disk. 


DMSSET 
Issues DIAGNOSE 64 FINDSYS to locate the CMSDOS or CMSBAM 


segments. If the segment is not already loaded, issues 
DIAGNOSE 64 LOADSYS to load it. 


DMSSET 
Sets up the $$B-transient area for use by VSE routines. 


DMSSET 
Sets up the LOCK/UNLOCK resource table. 


DMSSET 
If SET DOS OFF has been specified, issues the DIAGNOSE 64 
PURGESYS function for the CMSDOS and CMSBAM segments and, 
if VSAM has been loaded, for the CMSVSAM segment. 


QUERYING CMS ENVIRONMENT OPTIONS 


The QUERY command, which displays CMS environment options, is 
handled by eight modules. DMS@RY is the main module. The first 
time QUERY is invoked, DMSQRY established QUERY as a nucleus 
extension. DMSQRY acquires a work area and uses DMSQRZ to 
initialize it. 
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If the option queried is a CMS option and if the command has the 
correct syntax, DMSQRY passes control to the module that handles 

that option: DMSQ@RS, DMSQRT, DMS@RU, DMSQRYV, DMSQRW, or DMSQRX. 

The module called performs the requested QUERY function, then ) 
returns control to the original caller. 
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| ND EXECUTING CMS FILES 


As shown in Part 2 of Figure 9 on page 39 five general topics 

form the category "Process and Execute CMS Files." Two of these 

topics are discussed in this section: "Maintaining an 

oe Console Environment" and "Loading and Executing TEXT 
iles. 


MAINTAINING AN INTERACTIVE CONSOLE ENVIRONMENT 


Two levels of information are discussed in the following 
section. The first level is a general discussion of how CMS 
maintains an interactive console environment. The second level 
is a more detailed discussion of the methods of operation mainly 
responsible for this function. 


There are two major functions concerned with maintaining an 
interactive terminal environment for CMS: console management and 
command processing. The CMS module that manages the virtual 
machine console is DMSINT. The module responsible for command 
processing is DMSITS. Many CMS modules are called in support of 
these two functions, but the modules in the following list are 
primarily responsible for supporting the functions: 


DMSCRD 
Reads a line from the console. 


DMSCHR 
Writes a line to the console. 


DMSSCN 
Converts a command line to PLIST format. 


DMSINA 
Converts abbreviated commands to their full names. 


DMSCPF 
Passes a command line to CP for execution. 


MAINTAINING AN INTERACTIVE COMMAND/RESPONSE SESSION 


Three main lines of control maintain the continuity for an 
interactive CMS session: (1) handling of commands passed to 
DMSINT by the initialization module, DMSINS (2) handling of 
commands entered at the console during a session, and (3) 
handling of commands entered as subset commands. The following 
lists show the main logic paths for the first two functions. 


Execute Commands Passed via DMSINS 


DMSINT 
On entry from DMSINS, processes any commands passed via the 
console read put on the user's console by that routine. 
That is, processes any commands the user stacks on the line 
as the first read that DMSINT processes. In handling the 
first read, if that read is null, control passes to the 
main loop of the program, which is described in the 
following section. 


DMSINM 
Retrieves the current time. 


DMSCRD 
Branches to the waitread subroutine to read a command line 
at the console. 
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DMNSSCN 
Waitread then calls DMSSCN to convert the line just read 
into PLIST format. Once converted to PLIST format, an SVC 
202 is issued (at label INIT1A) to exacute the function. 
This cycle is repeated until all stacked commands are 
executed. 


DMSFNS 
When command execution completes, calls DMSFNS Cat label 
UPDAT) to close any files that may have remained open 
during the command processing. 


DMSVSR 
Ensures that any fields set by VSAM processing are reset 
for CMS. Also ensures that the VSAM discontiguous shared 
segment is purged. 


DMSINT 
Sets up an appropriate status message (CMS, CMS SUBSET, 
CMS/DOS, etc.). 


DMSCHWR 
Writes the status message to the console. 


Handle Commands Entered During a CMS Terminal Session 


DMSINT 
Branches (from label INLOOP2) to the waitread subroutine to 
read a line entered at the console. 


DMSCRD 
Reads a line entered at the console (subroutine waitread). 


DMSSCN 
Converts the command line to PLIST format (subroutine 
waitread). 


DMSINT 
Determines whether the command line is a null line or a 
comment. 


DMSLFS 
If the command line is neither a command line nor a 
comment, determines whether the command is an EXEC file. 


DMSINA (CABBREV) 
Determines whether the command is an abbreviation, and if 
it is, returns its full name. 


DMSITS 
Passes the command line to DMSITS via an SVC 202. DMSITS 
is the CMS SVC handler. For a detailed description of the 
SVC handler, see "Method of Operation for DMSITS." 


DMSCPF 
If the command could not be executed by the SVC handler, 
passes the command to CP to see if CP can execute it. 


DMSFNS 
On return from processing the command line (label UPDAT), 
closes any files that may have been opened during 
processing. 


DMSSMN 
Resets any flags or fields that may have been set during OS 
processing. 


DMSVSR 
Ensures that any fields set for VSAM processing are reset 
for CMS. Also ensures that the VSAM discontiguous shared 
segment is purged. 
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DMSINT 
When the command line has been successfully executed, 
builds a CMS ready message for the user (label PRNREADY). 


DMSCHWR 
Writes the ready message to the console. 


DMSINT 
Returns control to DMSINT at label INLOOP2 to continue 
monitoring the CMS terminal session. 


FOR DMSINT - CONSOLE MANAGER 


DMSINT, the console manager, maintains the continuity of 
operation of the CMS command environment. The main control loop 
of DMSINT is initiated by a call to DMSCRD to get the next 
command. When the command is entered, DMSINT calls DMSINM to 
initialize the CPU time for the new command and then puts it in 
both a standard tokenized and an extended parameter list form by 
calling the scan function program DMSSCN. After calling DMSSCN, 
DMSINT checks to see if an EXEC filetype exists with a filename 
of the typed-in command. (For example, if ABC was typed in, it 
checks to see if ABC EXEC exists.) If the EXEC file does exist, 
DMSINT adjusts register 1 to point to the same command set up by 
DMSSCN, but preceded by CL8'EXEC'. Then DMSINT issues an SVC 
202 7 ae the corresponding EXEC procedure ("ABC EXEC’ in the 
example). 


If no such EXEC file exists for the first word typed in, DMSINT 
makes a further check using the CMS abbreviation~check routine, 
DMSINA. If, for example, the first word typed in had been 'E', 
DMSINT looks up 'E*® via the DMSINA routine. If an equivalent is 
found for "E', DMSINT looks for an EXEC file with the name of 
the equivalent word (for example, EDIT EXEC). If such a file is 
found, DMSINT adjusts register 1 as described above to call the 
EXEC and substitutes the equivalent word, EDIT, for the first 
word typed in. Thus, if "E’ is a valid abbreviation for 'EDIT* 
and you have an EXEC file called EDIT EXEC, EDIT EXEC is invoked 
when you type in °E* from the terminal. 


If no EXEC file is found either for the entered command name or 
for any equivalent found by DMSINA, DMSINT leaves the terminal 
command as processed by DMSSCN and then issues an SVC 202 to 
pass control to DMSITS. DMSITS then passes control to the 
appropriate command program. When the command terminates 
execution, or if DMSITS cannot execute it, the return code is 
passed in register 15. 


A zero return code indicates successful completion of the 
command. A positive return code indicates that the command was 
completed, but with an apparent error. A negative code returned 
by DMSITS indicates that the typed in command could not be found 
or executed at all. 


In the last case, DMSINT assumes that the command is a CP 
command and issues a DIAGNOSE instruction to pass the command 
line to the CP environment. If the command is not a CP command, 
DMSINT calls DMSCWR to type a message indicating that the 
command is unknown and the main control loop of DMSINT is 
entered at the beginning. 


If the return code from DMSITS is positive or zero, DMSINT saves 
the return code briefly and calls module DMSAUD to update the 
master file directory (MFD) on the appropriate user's disk for 
the 800-byte records on disk, or to update the file directory 
and the allocation map, or the appropriate user's disk for the 
512-, 1K~, 2K~, or 4K-byte records on disk. DMSINT also frees 
the TXTLIB chain and releases pages of storage if required. 


After updating the file directory, DMSINT checks the return code 
that was passed back. If the code is zero, DMSINT types a ready 
message and the processor time used by the given command. 
Control is passed to the beginning of the main control loop of 
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DMSINT. If the return code is positive, an error message is 
typed, along with the processor time used. The command causes 
the typing of an error message with the format: DMSxxxnnnt 
"text' where DMSxxx is the module name, nnn is the message 
identification number, t is the message type, and 'text’ is the 
message explaining the error. Control is then passed to the 
beginning of the main control loop. 


FOR DMSITS - CMS SVC HANDLING ROUTINE 


DMSITS CINTSVC) is the CMS system SVC handling routine. Since 
CMS is SVC driven, the SVC interruption processor is more 
complex than the other interruption processors. 


The general operation of DMSITS is as follows: 

1. The SVC new PSW Clow-storage location X'60') contains, in 
the address field, the address of DMSITS1L. Thus, the DMSITS 
routine 15 entered whenever a supervisor call is executed. 

2. DMSITS allocates a system save area and auser save area. 

The user save area is a register save area used by the 
routine, which is tnvoked later as a result of the SVC call. 

3. The called routine is invoked (via a LPSW or BALR). 


4. Upon return from the called routine, the save areas are 
released. 


5. Control is returned to the caller (the routine that 
originally made the SVC call). 


The following expands upon various features of the general 
operation that has just been described. 


Types of SVCs and Linkage Conventions 


The types of SVC calls recognized by DMSITS, and the linkage 
conventions for each, are as follows: 


SVC 201: When a called routine returns control to DMSITS, the 
user storage key may be in the PSW. Because the called routine 
may also have turned on the problem bit in the PSW, the most 
convenient way for DMSITS to restore the system PSW is to cause 
another interruption, rather than to attempt the privileged Load 
PSW instruction. DMSITS does this by issuing SVC 201, which 
causes a recursive entry into DMSITS. DMSITS determines if the 
interruption was caused by SVC 201, and if so, determines if the 
SVC 201 was from within DMSITS. If both conditions are met, 
control returns to the instruction following the SVC 201 with a 
PSW that has the problem bit off and the system key restored. 


SVC 202: SVC 202 is the most commonly used SVC in the CMS 
system. It is used for calling nucleus-resident routines, 
nucleus extensions; and routines written as commands (for 
example, disk resident modules). 


A typical coding sequence for an SVC 202 call is the following: 


LA R1,PLIST 
SVC 202 
DC AL4CERRADD) 


The "DC AL4Caddress)" following the SVC 202 is optional and may 
be omitted if the programmer does not expect any errors to occur 
in the routine or command being called. If the DC statement is 
included, an error return is made to the address specified in 
the DC, unless the address is equal to 1. If the address is 
equal to 1, return is made to the next instruction after "DC 
AL4C1)". DMSITS determines whether this DC was inserted by 
examining the byte following the SVC call inline. If it is 
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nonzero, the statement following the SVC 202 is an instruction. 
If it is zero, then the statement is a "DC AL4Caddress)™ or "DC 
AL4C1)". 


If you want to ignore errors, use the following sequence: 


LA R1L,PLIST 
SVC 202 
DC AL4C1) 


Whenever SVC 202 is called, the contents of general purpose 
register 0 and general purpose register 1 are passed intact to 
the called routine. Register 1 must point to an eight-character 
string, which may be the start of a tokenized plist. This 
character string must contains the symbolic name of the routine 
or command being called. The SVC handler only examines the name 
and high-order byte of register 1. The called routine decides 
Whether to use the extended plist or the tokenized plist by 
examining the high-order byte of register l. 


Note: Although an extended plist is provided, the called 
routine may not be set up to use it. 


CMS Supplied 
Extended 
PLIST pouoeer 
in Register 0 


The call did not originate from an EXEC file or from a 
command typed at the terminal. 


X'ol’ The call is from an EXEC 2 EXEC or from the System 
Product Interpreter when "ADDRESS COMMAND" is 
specified. 


See "Dynamic Linkage/SUBCOM"™ in this manual. a 


Used by the System Product Interpreter for function 

calls. 

The command was invoked as an immediate command. This 
setting should never occur with SVC 202. 

The command was called as a result of its name being 
typed at the terminal, or by the CMDCALL command to 
invoke the command from EXEC 2, or from a System 


Product Interpreter EXEC when "ADDRESS CMS" is 
specified. 


The call is a result of a command invoked from a CMS 
EXEC file with &CONTROL set to something other than 
NOMSG or MSG. 


The call is a result of a command invoked from a CMS 
EXEC file with &CONTROL MSG in effect Cindicates that 
messages are to be displayed at the terminal). 


The call is the result of a command invoked from a CMS 
EXEC file with &CONTROL NOMSG in effect. 
This is an end-of-command call from DMSINT CCMS 


console command handler). See the NUCEXT command in 
the VM/SP CMS Command and Macro Reference for details. 


This is a service call from DMSABN CABEND) or from 
NUCXDROP. See the NUCEXT function in the VM/SP CMS 
Command and Macro Reference for details. 


Figure 10. SVC 202 - Contents of High-Order Byte of Register l 
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Tokenized PLIST: For a tokenized parameter list, the symbolic 

name of the function being called (8 character string, padded 

with blank characters on the right if needed) is followed by 
extra arguments depending on the actual routine or command ) 
called. These arguments must be "tokenized."™ Every parenthesis 

is considered an individual argument, and each argument may have 

a maximum length of eight characters. 


Extended PLIST: For an extended parameter list, no restriction 
is put on the structure of the argument list passed to the 
called routine or command. Register 0 points to the following 
consecutive words: 


DC ACCMDBEG)2 
DC ACARGBEG)® 
DC ACARGEND)*% 
DC ACcOo)5 


Notes: 


1. These four words can be moved to some location convenient 
for the command resolution routines or convenient for some 
other program executed between the caller's SVC 202 and 
entry to the program list for which the parameter list is 
intended. For this reason, the called program may not 
assume that additional words follow word 4, or that the 
storage address of these 4 words bears any relationship to 
other data addresses. 


2. For function calls in the System Product Interpreter, two 
additional words are available. See the VM/SP System 
Product Interpreter Reference for more information on 


function calls and the two additional words. 


The first three addresses are defined by: 


CMDBEG EQU x ») 
DC C'TESTPROG’ 
ARGBEG EQU x 
C'FILEZ! 


ARGEND EQU x 


CMDBEG EQU * indicates the beginning of the command name, ARGBEG 
EQU * indicates the beginning of the argument list, and ARGEND 
EQU ® indicates the end of the argument list. The left 
Adie after ‘'testprog’ is used as a delimiter to determine 
ARGBEG. 


Svc 203: SVC 203 is called by CMS macros to perform various 
internal system functions. SVC 203 is an SVC call where no 
parameter list is provided; for example, DMSFREE. The 
parameters are passed in registers 0 andl. 


Oo 
oO 


A typical sequence for an SVC 203 call follows: 


SVC 203 
DC H'code! 


The halfword decimal code following the SVC 203 indicates the 
specific routine being called. DMSITS examines this halfword 
code as follows: (1) the absolute value of the code is taken, 


N 


The first word gives the beginning address of the command. 

The second gives the beginning address of the argument list. 

4 The third gives the address of the byte immediately 
following the end of the argument list. 

5 The fourth word may be used to pass any additional 

information required by individually called programs. If 

this word is not used to pass additional information, it 

should be zero so programs receiving optional information -) 

eee word, may detect that none is provided in this 

call. 


a 
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using an LPR instruction, (2) the first byte of the result is 
ignored, and the second byte of the resulting halfword is used 
as an index into a branch table, (3) the address of the correct 
routine is loaded, and control is transferred to it as the 
called routine. 


It is possible for the address in the SVC 203 index table to be 
zero. In this case, the index entry contains an 8-byte routine 
or command name, which 1s processed in the same way as the 
8-byte name passed in the parameter list passed to SVC 202. 


The sign of the halfword code indicates whether the programmer 
expects an error return. If so, the code is negative; if not, 
the code is positive. Note that the sign of the halfword code 
has no effect on determining the routine that is to be called, 
because DMSITS takes the absolute value of the code to determine 
the called routine. 


Because only the second byte of the absolute value of the code 
is examined by DMSITS, seven bits (bits 1-7) are available as 
flags or for other uses. For example, DMSFREE uses these seven 
bits to indicate such things as conditional requests and 
variable requests. Therefore, DMSITS considers the codes H'*3' 
and H'259*" to be identical and handles them the same as H‘'-3' 
and H'-259', except for error returns. 


When an SVC 203 is invoked, DMSITS stores the halfword code into 
the NUCON location CODE203, so that the called routine can 
examine the seven bits made available to it. 


All calls made by SVC 203 should be made by macros with the 
macro expansion computing and specifying the correct halfword 
code. 


USER-HANDLED SVCS: The programmer may use the HNDSVC macro to 
specify the address of a routine that processes any SVC call for 
SVC numbers 0 through 200 and 206 through 255. If the HNDSVC 
macro is used, the linkage conventions are as required by the 
user specified SVC-handling routine. 


You cannot specify a normal or error return from a user-handled 
SVC routine. 


OS MACRO SIMULATION SVC CALLS: CMS supports selected SVC calls 
generated by OS macros, by simulating the effect of these macro 
calls. 


The proper linkages are set up by the OS macro generations. 
DMSITS does not recognize any way to specify a normal or error 
return from an OS macro simulation SVC call. 


VSE SVC CALLS: All SVC functions supported for CMS/DOS are 
handled by the CMS module DMSDOS. DMSDOS receives control from 
DMSITS Cthe CMS SVC handler) when that routine intercepts a VSE 
Can and finds that the DOSSVC flag in DOSFLAGS is set in 


DMSDOS acquires the specified SVC code from the OLDPSW field of 
the current SVC save area. Using this code, DMSDOS computes the 
address of the routine where the SVC is to be handled. 


Many CMS/DOS routines Cincluding DMSDOS) are contained in a 
discontiguous shared segment (DCSS). Most SVC codes are 
executed within DMSDOS, but some are in separate modules 
external to DMSDOS. If the SVC code requested is external to 
DMSDOS, its address is computed using a table called DCSSTAB. 
If the code requested is executed within DMSDOS, the table 
ia 1s used to compute the address of the code to handle the 


DOS SVC calls are discussed in more detail in "Simulating a VSE 
Environment Under CMS." 
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INVALID SVC CALLS: There are several types of invalid SVC calls 
recognized by DMSITS: 


e Invalid SVC number. If the SVC number does not fit into any 
of the classes described above, it is not handled by DMSITS. 
An error message 185 displayed at the terminal, and control 
is returned directly to the caller. 


° Invalid routine name in SVC 202 parameter list. If the 
routine named in the SVC 202 parameter list is invalid or 
cannot be found, DMSITS handles the situation in the same 
way it handles an error return from a legitimate SVC 
routine. The error code is —-3 


° Invalid SVC 203 code. If an invalid code follows SVC 203, 
an error message is displayed and the ABEND routine is 
called to terminate execution. 


Search Hierarchy for SVC 202 


SVC 202 ENTERED FROM A PROGRAM: When a program issues SVC 202 
and passes a routine or command name in the parameter list, 
DMSITS must search for the specified routine or command. (CIn 
the case of SVC 203 with a zero in the table entry for the 
specified index, the same logic must be applied.) 


The search order is as follows: 


1. A check i8 made to see if the specified name is a nucleus 
extension routine. If this is the case, then control goes 
to the specified nucleus extension routine (unless 
resolution to a nucleus extension is prohibited by a code 
value specified in the high-order byte of register 1). 


2. A check is made to see if there is a routine with the 
specified name currently occupying the system transient 
hata If this is the case, then control is transferred 
there. 


3. The system function name table is searched to see if a 
command by this name is a nucleus-resident command. If the 
search is successful, control goes to the specified nucleus 
routine. 


4. A search is then made for a disk file with the specified 
name as the filename and MODULE as the filetype. The search 
is made in the standard disk search order. If this search 
is successful, the specified module is loaded (via the 
LOADMOD command) and control passes to the storage location 
now occupied by the command. 


5. If all searches so far have failed, DMSINA CABBREV) is 
called to see if the specified routine name is a valid 
system abbreviation for a system command or function. 
User-defined abbreviations and synonyms are also checked. 

If this search is successful, steps 1 through 4 are repeated 
with the full function name. 


6. If all searches fail,» an error code of -3 is issued. 


COMMANDS ENTERED FROM THE TERMINAL: When a command is entered 
from the terminal, DMSINT processes the command line and calls 
the scan routine to convert it into a tokenized parameter list 
consisting of eight-byte entries and an extended parameter list 
as previously described. The following search is performed: 


1. DMSINT searches for a disk file whose filename is the 
command name and whose filetype is EXEC. If this search is 
successful, EXEC is invoked to process the EXEC file. If 
not found, the command name is considered to be an 
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abbreviation and the appropriate tables are examined. If 
found, the abbreviation is replaced by its full equivalent 
and the search for an EXEC file is repeated. 


If there is no EXEC file, DMSINT executes SVC 202 passing 
the scanned tokenized parameter list, with the command name 
in the first eight bytes of the plist pointed to by register 
l and the extended plist address in register 0. SITS 
performs the search described for SVC 202 in an effort to 
execute the command. 


If DMSITS returns to DMSINT with a return code of ~-3 

indicating that the search was unsuccessful, DMSINT uses the 

ao patie facility to attempt to execute the command as a 
command. 


If all of these searches fail, DMSINT displays the error 
message UNKNOWN CP/CMS COMMAND. 


Figure 1l on page 60 for a description of this search for a 


command name. 
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User enters name 
at terminal 


Read line from 


terminal 
(name. .."') 


Implied EXEC 
Now in Effect 
(Note 1) 


Expand Line by 


Does file Inserting the 
“name EXEC” command name 
exist EXEC to: 

EXEC name 


Is name 
a Synonym 
or abbreviation for 
some real 
name 


Name is now the Yes 
real name from a 


Synonym Table 


Issue SVC 202 
(See the SVC 202 
Subroutine) 


Is RC=-3 
(Note 2) 


Notes: 


1. If the terminal line was actually from an EXEC file, or if the 
command SET IMPEX OFF has been executed, implied EXEC is 
not in effect. 


2. A-3 return code indicates SVC 202 processing did not find 
the command. 


3. If the terminal line was actually from an EXEC file, or if the 
command SET IMPEX OFF has been executed, implied CP is 
not in effect. 


Implied CP 
now in Effect 
(Note 3) 


Pass line to CP 
for processing 


Was 
command found 
and executed 


Display 
UNKNOWN 
CP/CMS 

COMMAND 


Display Ready 
message with 


error code of 
ifRC #0 


Figure ll (Part 1 of 2). CMS Command Cand Request) Processing 
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High order byte No 


=X‘Q3’ or X‘04" 


Nucleus extension Look aside buffer 


Is name 
now in 
transient 
area 


Is name 
now in 
transient 
area 


Pats control to 
routine in 
transient area 


Is name 
a@ nucleus 
function 


Attempt to execute 
LOADMOD name 
module from disk 


Was the 
LOADMOD 
successful 


Is name 
a Synonym 
or abbreviation for 
some real 
name 


Pass control to the 
routine (in the 
nucleus or user area) 
to execute the 
command 


Return to routine 
that issued the 
SVC 202 


Upon completion 
return to SVC 
routine 


Figure ll (Part 2 of 2). CMS Command Cand Request) Processing 
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User and Transient Program Areas 


There are two areas that can hold program modules that are 
loaded by LOADMOD from the disk. These are called the user 
program area and the transient program area. (See Figure 4 on 
page 16 for a description of CMS storage usage.) A summary of 


CMS modules and their attributes, including whether they reside 
in the user program area or the transient area, is contained in 


the VM/SP CMS Command and Macro Reference. 


The user program area starts at location X'20000' and extends 
upward to the loader tables. However, the high-address end of 
that area can be allocated as free storage by DMSFREE. 
Generally, all user programs and certain system commands, such 
as EDIT and COPYFILE, are executed in the user program area. 
Because only one program can be executing in the user program 
area at one time, unless it is an overlay structure, it is 
impossible for one program in the user program area to invoke, 
by means of SVC 202, a module that is also intended to execute 
the user program area. 


The transient program area is two pages, running from location 
X*E000" up to and including location X'FFFF'. It provides an 


area for system commands that may also be invoked from the user 


program area by means of an SVC 202 call. For example, a 
program in the user program area may invoke the SET command 


because this command is loaded into the transient program area. 


When a transient module is called by an SVC, it is normally 


executed with the PSW system mask disabled for I/0 and external 


interrupts. 


A program executing in the transient program area may not invoke 


another program intended to execute in the transient program 
area. Thus, for example, a program executing in the transient 
program area may not invoke the SET command. 


There is one further functional difference between the use of 
the two program areas. DMSITS starts a program in the user 

program area so that it is enabled for all interruptions. It 
starts a program in the transient program area so that it is 
disabled for all interruptions. Thus, the individual program 


may have to use the SSM (Set System Mask) instruction to change 


the current status of its system mask. 


Called Routine Start-Up Table 


Figure 12 and Figure 13 show how the PSW and registers are set 


up when the called routine is entered. 


Storage Problem 
Called et eee maa 4 


SVC 202 or | SVC 202 or 203 - Nucleus Resident —_| ~- Nucleus Resident | Disabled | | System | 


a er 
[sve 202 or 205 ~ Transient area MODULE | Disabled | User | off 
[sve 202 or 203 user aren | Enabled | userid ore 
Tuser-hendied ——SSCS™S~*~*~*~dCnabdw “der id 
[os-vSe - Nucleus resident + Dvaabied | Syaten——~ ore 
[08-¥5E = Transient eres nodule | Disabled | syaten [ofr 


Figure 12. PSW Fields when Called Routine is Started 
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svc 202 Same as Unpredictable Address 
or 203 caller of 

t called 

routine 


Other Same as Same as 
caller caller f 
routine DMSITS 


Figure 13. Register Contents when Called Routine is Started 


Returning to the Caller 


When the called routine is finished processing, it returns 
control to DMSITS, which then must return control to the calling 
routine. 


RETURN LOCATION: The return is effected by loading the original 
SVC old PSW (that was saved at the time DMSITS was first 
entered), after possibly modifying the address field. How the 
address field is modified depends on the type of SVC call and on 
whether the called routine indicated an error return address. 


For SVC 202 and 203, the called routine indicates a normal 
return by placing a zero in register 15 and an error return by 
placing a nonzero in register 15. If the called routine 
indicates a normal return, then DMSITS makes a normal return to 
the calling routine. If tha called routine indicates an error 
return, then DMSITS returns to the caller's error return 
address, if one was specified. If no error return address was 
specified, DMSITS abnormally terminates. 


For SVC 202 not followed by "DC AL4Caddress)™ or "DC AL4(1)", a 
normal return is made to the instruction following the SVC 
instruction and an error return causes an abnormal termination. 
For an SVC 202 followed by "DC AL4Caddress)™, a normal return is 
made to the instruction following the DC and an error return is 
made to the address specified in the DC unless the address is 
equal to 1. If the address is 1, return is made to the next 
instruction after the "DC AL4(1)" instruction. In either case, 
eegiayer 15 contains the return code passed by the called 
routine. 


For SVC 203 with a positive halfword code, a normal return is 
made to the instruction following the halfword code and an error 
return causes an abnormal termination. For SVC 203 with a 
negative halfword code, both normal and error returns are made 
to the instruction following the halfword code. In any case, 
Sot) aad 15 contains the return code passed back by the called 
routine. 


For OS macro simulation SVC calls and user-handled SVC calls, no 
error return is recognized by DMSITS. As a result, DMSITS 
always returns to the calling routine by loading the SVC old PSW 
that was saved when DMSITS was first entered. 


REGISTER RESTORATION: Upon entry to DMSITS, all registers are 
saved as they were when the SVC instruction was first executed. 
Upon exiting from DMSITS, all registers are restored to the 
values that were saved at entry. 


The exception to this is register 15 for SVC 202 and 203. Upon 
return to the calling routine, register 15 contains the value 
that was in register 15 when the called routine returned to 
DMSITS after it had completed processing. 
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Modification of the System Save Area 


If the called routine has system status, so that it runs with a 
PSW storage protect key of 0, it may store new values into the ; | 
system save area. 


If the called routine wishes to modify the location where 
control is to be returned, it must modify the following fields: 


e For SVC 202 and 203, it must modify the NUMRET and ERRET 
(normal and error return address) fields. 


e For other SVCs, it must modify the address field of OLDPSW. 


To modify the registers that are to be returned to the calling 
routine, the fields EGPR1L, EGPR2, ..., EGPR15 must be modified. 


If this action is taken by the called routine, the SVCTRACE 
facility may print misleading information, since SVCTRACE 
assumes that these fields are exactly as they were when DMSITS 
was first entered. Whenever an SVC call is made, DMSITS 
allocates two save areas for that particular SVC call. Save 
areas are allocated as needed. For each SVC call, a system and 
user save area are needed. 


When the SVC-called routine returns, the save areas are not 
released, but are kept for the next SVC. At the completion of 
ay eee all SVC save areas allocated by that command are 
released. 


DMSITS uses the system save area (DSECT SSAVE) to save the value 
of the SVC old PSW at the time of the SVC call, the calling 
routine's registers at the time of the call, and any other 
necessary control information. Since SVC calls can be nested, 
there can be several of these save areas at one time. The 
system save area is allocated in protected free storage. 


The user save area (DSECT EXTUAREA) contains 12 doublewords (24 2 
words) allocated in unprotected free storage. DMSITS does not 
use this area at all; it simply passes a pointer to this area 
(via register 13.) The called routine can use this area as a 
temporary work area or as a register save area. There is one 
user save area for each system save area. The USAVEPTR field in 
the system save area points to the user save area. 


The exact format of the system save area can be found in the 
VM/SP Data Areas and Contr Bloc ogic, Volum - The 
most important fields and their uses are as followns: 


Field Usage 


CALLER (Fullword) The address of the SVC instruction 
that resulted in this call. 


CALLEE (Doubleword) Eight-~byte symbolic name of the 
called routine. For OS and user-handled SVC 
calls, this field contains a character string 
of the form SVC nnn, where nnn is the SVC 
number in decimal. 


CODE CHalfword) For SVC 203, this field contains the 
halfword code following the SVC instruction 
line. 


OLDPSW (Doubleword) The SVC old PSW at the time that 
DMSITS was entered. 
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Field Usage 


NRMRET CFullword) The address of the calling routine 
where control is to be passed if there is a 
normal return from the called routine. 


ERRET (Fullword) The address of the calling routine 
where control is to be passed if there is an 
error return from the called routine. 


EGPRS (16 Fullwords, separately labeled EGPRO, EGPRI, 
EGPR2, EGPR3, ..., EGPR15) The entry 
registers. The contents of the general 
registers at entry to DMSITS are stored in 
these fields. 


EFPRS (4 Doublewords, separately labeled EFPRO, 
EFPR2, EFPR4, EFPR6) The entry floating-point 
registers. The contents of the floating-point 
registers at entry to DMSITS are stored in 
these fields. 


SSAVENXT (Fullword) The address of the next system save 
area in the chain. This points to the system 
save area that is being used, or will be used, 
for any SVC call nested in relation to the 
current one. 


SSAVEPRV (CFullword) The address of the previous system 
save area in the chain. This points to the 
system save area for the SVC call in relation 
to which the current call is nested. 


USAVEPTR (CFullword) Pointer to the user save area for 
this SVC call. 


Dynamic Linkage/SUBCOM 


It is possible for programs that are already loaded from disk to 
become dynamically known by name to CMS for the duration of the 
current command; such programs can be called via SVC 202. These 
programs can also make other programs dynamically known if first 
program can supply the entry points of the other programs. 


To become known dynamically to CMS, a program or routine invokes 
the create function of SUBCOM. To invoke SUBCOM, issue the 
following calling sequence from an assembler program (Register 1 
must point to this calling sequence): 


LA LA R1,PLIST 

SVC 202 

DC AL4CERROR) 

PLIST DS OF 
DC CL&'*SUBCOM'® 

SUBCNAME DC CL8&'name' COMMAND NAME 

SUBCPSW DC xXL2'0000' SYSTEM MASK, STORAGE KEY, ETC. 
DC AL2(0) RESERVED 

SUBCADDR DC ACX-) ENTRY ADDRESS, -1l FOR QUERY 
DC Aco) USER WORD 


SUBCOM creates an SCBLOCK control block containing the 
information specified in the SUBCOM parameter list. SVC 202 
uses this control block to locate the specified routine. The 
SUBCOM chain of SCBLOCKs is released at the completion of the 
command (that is, when CMS displays the Ready message). See the 
publication VM/SP Data Areas and Control Block Logic, Volume 2 
CCMS), for a description of the SCBLOCK control block. 
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When a program issues an SVC 202 call to a program that has 

become known to CMS via SUBCOM, it places X'02' in the 

high-order byte of register one. Control passes to the called 

program at the address specified by the called program when it J 
invoked SUBCOM. 


The PSW specifies the system mask, the PSW key to be used, the 
program mask Cand initial condition code), and the starting 
address for execution. The problem-state bit and machine-check 
bit may be set. The machine-check bit has no effect in CMS 
under CP. The EC-mode bit and wait-~state bit cannot be set 
(they are always forced to zero). Also, one 4-byte user-defined 
word can be associated with the SUBCOM entry point, and referred 
to when the entry point is subsequently called. 


Note: When control passes to the specified entry point, the 
register contents are: 


R2 Address of SCBLOCK for this entry point. 
R12 Entry point address. 

R13 24-word save area address. 

R14 Return address (CMSRET). 

R15 Entry point address. 


You can also use SUBCOM to delete this potential linkage to the 
program or routine'’s SCBLOCK or to determine if an SCBLOCK 
exists for a program or routine. To delete a program or 
routine's SCBLOCK, issue: 


DC CL8‘'SUBCOM! 
DC CL8'program or routine name® 
DC 8X'00° 


To determine if a SCBLOCK exists for a program or routine, J 
1ssue: 


DC CL&8*SUBCOM’ 

DC CL8&'program or routine name’ 

DC ACO) SCBLOCK address as a returned value 
DC 4X'FF* 


Note that if "SUBCOM name’ is called from an EXEC file, the 
QUERY PLIST is the form of PLIST which will be issued. 


To query the chain anchor issue: 


DC CL8&‘'SUBCOM* 


DS CL8& (contents not relevant) 

DS ALG Will receive chain anchor 
contents from NUCSCBLK. 

DC AL4(1) Indicates request for anchor. 


Note that the anchor will be equal to F'O' if there are no 
SCBLOCKs on the chain. 


Return codes from SUBCOM are: 


0 - Successful completion. A new SCBLOCK was created, 
the specified SCBLOCK was deleted, or the specified 
Program or routine has an SCBLOCK. 

1 - No SCBLOCK exists for the specified program or 
routine. This is the return code for a delete or a 
query. 

25 - No more free storage available. SCBLOCK cannot be 
created for specified program or routine. 
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Note: If you create SCBLOCKs for several programs or routines 
with the same name, they will all be remembered, but SUBCOM uses 
the last one created. A SUBCOM delete request for that name 
will eliminate only the most recently created SCBLOCK, making 
active the next most recently created SCBLOCK with the same 
name. 


When control returns to CMS after a console input command has 
terminated, the entire SUBCOM chain of SCBLOCKs is released; 
none of the subcommands established during that command are 
carried forward to be available during execution of the next 
console command. 


OADING EXECUTING TEXT FILES 


The CMS loader consists of a nucleus resident loader (DMSLDR), a 
file and message handler program C(CDMSLIO), a library search 
program (DMSLIB), and other subroutine programs. DMSLDR starts 
loading at the user first location CAUSRAREA) specified in NUCON 
or at a user specified location. When performing an INCLUDE 
function, loading resumes at the next available location after 
the previous LOAD, INCLUDE, or LOADMOD. 


The loader reads in the entire user's program, which consists of 
one or more control sections, each defined by a type 0 ESD 
record ("card"). Each control section contains a type l ESD 
card for each entry point and may contain other control cards. 


Once the user's program is in storage, the loader begins to 
search its files for library subprograms called by the program. 
The loader reads the library subprograms into storage, 
relocating and linking them as required. To relocate programs, 
the loader analyzes information on the SLC, ICS, ESD, TXT, and 
REP cards. To establish linkages, it operates on ESD and RLD 
cards. Information for end-of-load transfer of control is 
provided by the END and LDT cards, the ENTRY control card, START 
command, or RESET option. 


The loader also analyzes the options specified on the LOAD and 
INCLUDE commands. In response to specified options, the loader 
can: 

e Set the load area to zeros before loading (CLEAR option). 

e Load the program at a specified location CORIGIN option). 


e Suppress creation of the load-map file on disk (CNOMAP 
option). 


° Suppress the printing of invalid card images in the load map 
CNOINV option). 


° Suppress the printing of REP card images in the load map 
CNOREP option). 


e Load program into "transient area™ (ORIGIN TRANS option). 

e Suppress TXTLIB search (CNOLIBE option). 

e Suppress text file search CNOAUTO option). 

e Execute the loaded program (START option). 

e Type the load map CTYPE option). 

e Set the program entry point (RESET option). 

During its operation, the loader uses a loader table (REFTBL), 
and external symbol identification table CESIDTB), and a 
location counter CLOCCNT). The loader table contains the names 
of control sections and entry points, their current location, 


and the relocation factor. (The relocation factor is the 
difference between the compiler-assigned address of a control 
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SLC CARD ROUTINE 


section and the address of the storage location where it is 

actually loaded.) The ESIDTB contains pointers to the entries 

in REFTBL for the control section currently being processed by ‘ 
the loader. The loader uses the location counter to determine ) 
where the control section is to be loaded. Initially, the 

loader obtains from the nucleus constant area the address 

CLOCCNT) of the next location at which to start loading. This 

value is subsequently incremented by the length indicated on an 

aed 0), END, or ICS card, or it may be reset by an SLC 

card. 


The loader contains a distinct routine for each type of input 
card. These routines perform calculations using information 
contained in the nucleus constant area, the location counter, 
the ESIDTB, the loader table, and the input cards. Other loader 
routines perform initialization, read cards into storage, handle 
error conditions, provide disk and typewritten output, search 
libraries, convert hexadecimal characters to binary, process 
end-of-file conditions, and begin execution of programs in core. 


Following are descriptions of the individual subprocessors with 
LDR. 


Function 
This routine sets the location counter (LOCCT) to the 
address specified on an SLC card or to the address assigned 
Cin the REFTBL} to a specified symbolic name. 


Entry 
The routine is entered at the first instruction when it 
receives control from the initial and resume loading 
routine. It is entered at ORG2 whenever a loader routine 
requires the current address of a symbolic location 
specified on an SLC card. 
3 


Operation 
This routine determines which of the following situations 
exists, and takes the indicated action: 


1. The SLC card does not contain an address or a symbolic 
name. The SLC card routine branches, via BADCRD in the 
reference table search routine, to the disk and type 
output routine (DMSLIO), which generates an error 
message. 


2. The SLC card contains an address only. The SLC card 
routine sets the location counter (LOCCT) to that 
address and returns to RD, in the initial and resume 
loading routine, to read another card. 


3. The SLC card contains a name only, and there is a 
reference table entry for that name. The SLC card 
routine sets LOCCT to the current address of that name 
Cat ORG2) and returns to the initial and resume loading 
routine to get another card. 


4. The SLC card contains a name only, and there is no 
reference table entry for that name. The SLC card 
routine branches via ERRSLC to the disk and type output 
routine (DMSLIO), which generates an error message for 
that name. 


5. The SLC card contains both an address and a name. If 
there is a REFTBL entry for the name, the sum of the 
current address of the name and the address specified 
on the SLC card is placed in LOCCT. Control returns to 
the initial and resume loading routine to get another 
card. If there is no REFTBL entry for the name, the 
SLC card routine branches via ERRSLC to the disk and ) 
type output routine, which generates an error message 
for the name. 
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Function 
This routine establishes a reference table entry for the 
control-segment name on the ICS card if no entry for that 
name exists, adjusts the location counter to a fullword 
boundary, if necessary, and adds the card-speci fied 
control-segment length to the location counter, if 
necessary. 


Entry 
This routine has one entry point, C2AE1. The routine is 
entered from the initial and resume loading routine when it 
finds an ICS card. 


Operation 


1. The routine begins its operation with a test of card 
type. If the card being processed is not an ICS card, 
the routine branches to the ESD card analysis routine. 
Otherwise, processing continues in this routine. 


2. The routine tests for a hexadecimal address on the ICS 
card. If an address is present, the routine links to 
the DMSLSBA subroutine to convert the address to 
binary. Otherwise, the routine branches via BADCRD to 
the disk and type output routine (DMSLIO). 


3. The routine next links to the REFTBL search routine, 
which determines whether there is a reference table 
entry for the card-specified control-segment name. If 
such an entry is found, the REFTBL search routine 
branches to the initial and resume loading routine. 
Otherwise, the REFTBL search routine places the 
control-segment name in the reference table and 
processing continues. 


4. The routine determines whether the card~speci fied 
control-segment length is zero or greater than zero. 
If the length is zero, the routine places the current 
location counter value in the reference table entry as 
the control segment's starting address (ORG2), and then 
it branches to the initial and resume loading routine. 
If the length is greater than zero, the routine sets 
the current location counter value at a fullword 
boundary address. The routine then places this 
adjusted current location counter value in the 
reference table entry, adjusts the location counter by 
adding the specified control-segment length to it, and 
branches to RD in the initial and resume loading 
routine to get another card. 


ESD TYPE 0 CARD ROUTINE <- C3AA3 


Function 
This routine creates loader table and ESID table entries 
for the card-specified control section. 


Entry 
This routine has one entry point, C3AA3. The routine is 
entered from the ESD card analysis routine. 


Operation 


l. If this is the first section definition, its ESDID is 
proved. 


2. This routine first determines whether a loader table 
CREFTBL) entry has already been established for the 
card-specified control section. To do this, the 
routine links to the REFTBL search routine. The ESD 
type 0 card routine's subsequent operation depends on 
Whether there already is a REFTBL entry for this 
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control section. If there is such an entry, processing 
continues with operation 5, below; if there is not, the 
REFTBL search routine places the name of this control 
section in REFTBL and processing continues with 
operation 3. 


The routine obtains the card-specified control section 
length and performs operation 4. 


The routine links to location C2AJ1 in the ICS card 
routine and returns to C3AD4 to obtain the current 
storage address of the control section from the REFTBL 
entry, inserts the REFTBL entry position (N - where 
this is the Nth REFTBL entry) in the card-specified 
ESID table location, and calculates the difference 
between the current (relocated) address of the control 
section and its card-specified Cassembled) address. 
This difference is the relocation factor. It is placed 
in the REFTBL entry for this control section. If 
previous ESDs have been waiting for this CSECT, a 
branch is taken to SDDEF, where the waiting elements 
are processed. A flag is set in the REFTBL entry to 
indicate a section definition. 


The entry found in the REFTBL is examined to determine 
whether it had been defined by a COMMON. If so, it is 
converted from a COMMON to a CSECT and performs 
operation 3. 


If the entry had not been defined previously by an ESD 
type 0, processing continues at 3. 


If the entry had been defined previously as other than 
COMMON, DMSLIO is called via ERRORM to print a warning 
message, "DUPLICATE IDENTIFIER". The entry in the ESID 
table is set to negative so that the CSECT is skipped 
(that is, not loaded) by the TXT and RLD processing 
routines. 


ESD TYPE 1 CARD ROUTINE - ENTESD 


70 


Function 


This routine establishes a loader table entry for the entry 
point specified on the ESD card, unless such an entry 
already exists. 


Entry 


This routine is entered from the ESD card analysis routine. 


Operation 


Ls 


Branches and links to REFADR to find loader table entry 
for first section definition of the text deck saved by 
the ESD 0 routine. 


The routine then adds the relocation factor and the 

address of the ESD found in operation 1 or the address 
in LOCCNT if an ESD has not yet been encountered. The 
sum is the current storage address of the entry point. 


The routine links to the REFTBL search routine to find 
whether there is already a REFTBL entry for the 
card-specified entry point name. If such an entry 
exists, the routine performs operation 4. If there is 
no entry, the routine performs operation 5. 


Upon finding a REFTBL entry that has been previously 
defined for the card-specified name, the routine then 
compares the REFTBL-specified current storage address 
with the address computed in operation 2. If the 
addresses are different, the routine branches and links 
to the DMSLIO routine (duplicate symbol warning); if 
the addresses are the same, the routine branches to 
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location RD in the initial and resume loading routine 
to read another card. Otherwise, it is assumed that 
the REFTBL entry was created as a result of previously 
encountered external references to the entry. The 
DMSLSBC routine is called to resolve the previous 
external references and adjust the REFTBL entry. The 
ae name and address are printed by calling 
DMS 3 


5. If there is no REFTBL entry for the card-speci fied 
entry point name, the routine makes such an entry and 
branches to the DMSLIO routine. 


C3AHL 


ion 

This routine creates the proper ESID table entry for the 
card-specified external name and places the name's assigned 
address (ORG2) in the reference table relocation factor for 
that name. 


This routine has two entry points: C3AHI1 and ESDOO. 
Location C3AH1 is entered from the ESD card analysis 
routine. This occurs when an ESD type 2 card is being 
processed. Location ESD00 is entered from: 


e The ESD card analysis routine, when the card being 
processed is an ESD type 2 and an absolute loading 
process is indicated. 


e The ESD type 0 card routine and ESD type 1 card 
routine, as the last operation in each of these 
routines. 


tion 


1. When this routine is entered at location C3AHI, it 
first links to the REFTBL search routine to determine 
whether there is a REFTBL entry for the card-speci fied 
external name. If none is found, the REFTBL search 
routine sets the undefined flag for the new loader 
table entry. 


2. The routine resets a possible WEAK EXTRN flag. The 
routine next places the REFTBL entry's position-key in 
the ESID table. If the entry has already been defined 
by means of an ESD type 0, 1, 5, or 6, processing 
continues at operation 4. Otherwise, it continues at 
operation 3. 


3. The relocated address is placed in the RELFAC entry in 
the external name's REFTBL entry. 


G4. The ESD type 2 card routine then determines (at 
location ESD00) whether there is another entry on the 
ESD card. If there is another entry, the routine 
branches to location CA3Al in the ESD card analysis 
routine for further processing of this card. 
Otherwise, the routine branches to location RD in the 
initial and resume loading routine. 


This routine exits to location CA3Al1 in the ESD card 
analysis routine if there is another entry on the ESD card 
being processed, and it exits to location RD in the initial 
and resume loading routine if the ESD card requires no 
further processing. 
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Function 
This routine makes loader table and ESIDTAB entries for J 
private code CSECT. 


Operation 


1. The routine LDRSYM is called to generate a unique 
character string number of the form 00000001, which is 
left in the external data area NXTSYM. It is greater 
in value than the previously generated symbol. 


2. The CSECT is then processed as a normal type 0 ESD with 
the above assigned name. 


ESD TYPES 5 AND 6 CARD ROUTINE - PRVESD AND COMESD 


Function 
This routine creates a reference table and ESIDTAB entries 
for common and pseudo-register ESDs. 


Operation 


1. Links to ESIDINC in the ESD type 0 card routine to 
update the number of ESIDTB entries. 


2. Links to the REFTBL search routine to determine wheather 
a reference table (CREFTBL) entry has already been 
created. If there is no entry, the REFTBL search 
routine places the name of the item in the REFTBL. 


3. If the REFTBL search routine had to create an entry for 
the item, the ESD type 5 and 6 card routine indexes it 
in the ESIDTB, enters the length and alignment in the 
entry, indicates whether it is a PR or common, and 
branches to ESD00 in the ESD type 2 card routine to 
determine whether the card contains additional ESDs to 
be processed. If the entry is a PR, the ESD type 5 and 
6 card routine enters its displacement and length in 
the REFTBL before branching to ESDOO. 


G4. If the REFTBL already contained an entry, the ESD type 
5 and 6 card routine indexes it in the ESIDTB, checks 
alignment, and branches to ESDO0. 


Note: The PR alignment is coded and placed into the REFTBL. It 
is an error to encounter more restrictive alignment PR than 
previously defined. A blank alignment factor is translated to 
fullword alignment. 


ESD TYPE 10 ROUTINE - WEAK EXTRN 


The WEAK EXTRN routine calls the search routine to find the 
EXTRN name in the loader table. If not found, set the WEAK 
EXTRN flag in the new loader table entry. Exit to ESDOQ. 


TXT CARD ROUTINE - C4AA1 


Function 
This routine has two functions: address inspection and 
placing text in storage. 


Entry 
This routine has three entry points: C4AAl1, which is 
entered from the ESD card analysis routine, and REPENT and 
APR1, which are entered from the REP card routine for 


address inspection. > 


72 VM/SP System Logic and Problem Determination Guide (CMS) 


Licensed Material--Property of IBM 
Operation 


1. This routine begins its operation with a test of card 
type. If the card being processed is not a TXT card, 
the routine branches to the REP card routine. 
Otherwise, processing continues in this routine. 


2. The routine then determines how many bytes of text are 
to be placed in storage and finds whether the loading 
process is absolute or relocating. If the loading 
process is absolute, the routine performs operation 4, 
below; if relocating, the routine performs operation 3. 


3. If the ESIDTB entry was negative, this is a duplicate 
to CSECT and processing branches to RD. Otherwise, the 
routine links to the REFADR routine to obtain the 
relocation factor of the current control segment. 


4. The routine then adds the relocation factor (0, if the 
loading process is absolute) and the card-speci fied 
storage address. The result is the address at which 
the text must be stored. This routine also determines 
whether the address is such that the text, when loaded 
starting at that address, overlays the loader or tha 
reference table. If a loader overlay or a reference 
table overlay is found, the routine branches to the 
LDRIO routine. If neither condition is detected, the 
routine proceeds with address inspection. 


5. The routine then determines whether an address has 
already been saved for possible use as the end-of-load 
branch address. If an address has been saved, the 
routine performs operation 7. If not, the routine 
performs operation 6. 


6. The routine determines whether the text address is 
below location 128. If the address is below location 
128, it should not be saved for use as a possible 
end-of-load branch address, and the routine performs 
operation 7. Otherwise, the routine saves the address 
and then performs operation 7. 


7. The routine then stores the text at the address 
specified Cabsolute or relocated) and branches to 
location RD in the initial and resume loading routine 
to read another card. 


Exits 
The routine exits to two locations: 


1. The routine exits to location RD in the initial and 
resume loading routine if it is being used to process a 
TXT card. 


2. The routine exits to location APRIL in the REP card 
routine if it is being used for REP card address 
inspection. 


REP CARD ROUTINE - C4AA3 


Function 
This routine places text corrections in storage. 


Entry 
This routine has one entry point, C4AA3. The routine is 
entered from the TXT card routine. 


Operation 


1. This routine begins its operation with a test of card 
type. If the card being processed is not a REP card, 
the routine branches to the RLD card routine. 
Otherwise, processing continues in this routine. 
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2. The routine then links to the HEXB conversion routine 
to convert the REP card-specified correction address 
from hexadecimal to binary. 


3. The routine then links to the HEXB conversion routine 
again to convert the REP card-specified ESID from 
hexadecimal to binary. 


4. The routine then determines whether the 2-byte 
correction being processed is the first such correction 
on the REP card. If it is the first correction, the 
routine performs operation 5. Otherwise, the routine 
performs operation 6. 


5. When the routine is processing the first correction, it 
links to location REPENT in the TXT card routine, where 
the REP card-specified correction address is inspected 
for loader overlay and for end-of-load branch address 
saving. In addition, if the loading process is 
relocating, the relocated address is calculated and 
checked for reference table overlay. The routine then 
performs operation 7. 


6. When the correction being processed is not the first 
such correction on the REP card, the routine branches 
to location APR1 in the TXT card routine for address 
inspection. 


7. The routine then links to the HEXB conversion routine 
to convert the correction from hexadecimal to binary, 
places the correction in storage at the absolute 
(card-specified) or relocated address, and determines 
whether there is another correction entry on the REP 
card. If there is another entry, the routine repeats 
its processing from operation 4, above. Otherwise, the 
routine branches to location RD in the initial and 
resume loading routine. 


Exits 
When all the REP-card corrections have been processed, this 
routine exits to location RD in the initial and resume 
loading routine. 


RLD CARD ROUTINE - CS5AA1L 


Function 
This routine processes RLD cards, which are produced by the 
assembler when it encounters address constants within the 
program being assembled. This routine places the current 


storage address (absolute or relocated) of a given defined . 


symbol or expression into the storage location indicated by 
the assembler. The routine must calculate the proper value 
of the defined symbol or expression and the proper address 
at which to store that value. 


Entry 
This routine has two entry points, C5AAl1L and PASSTWO. 


Operation 


1. Location C5AAl1 writes each RLD card into a work file 
CDMSLDR CMSUT1). Exit to RD to process the next card. 


Location PASSTWO reads an RLD card from the work file. 
At EOF get to C6AB6 to finish this file. 


2. The routine uses the relocation header (RH ESID) on the 
card to obtain the current address (absolute or 
relocated) of the symbol referred to by the RLD card. 
This address is found in the relocation factor section 
of the proper reference table entry. If the RH ESID is 
0, the routine branches to the LDRIO routine Cinvalid 
ESD). 
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3. The routine uses the position header (PH ESID) on the 
card to obtain the relocation factor of the control 
segment in which the DEFINE CONSTANT assembler 
instruction occurred. If the PH ESID is 0, the routine 
branches to BADCRD in the REFTBL search routine 
Cinvalid ESID). If the ESIDTAB entry is negative 
Cduplicate CSECT), the RLD entry is skipped. 


4. The routine next decrements the card-specified byte 
count by 4 and tests it for 0. If the count is now 0, 
the routine branches to location RD in the initial and 
resume loading routine. Otherwise, processing 
continues in this routine. 


5. The routine determines the length, in bytes, of the 
address constant referred to in the RLD card. This 
length is specified on the RLD card. 


6. The routine then adds the relocation factor obtained in 
operation 3 (relocation factor of the control segment 
in which the current address of the symbol must be 
stored) and the card-specified address. The sum is the 
current address of the location at which the symbol 
address must be stored. 


7. The routine then computes the arithmetic value (symbol 
address or expression value) that must be placed in 
storage at the address calculated in operation 6, 
above, and places that value at the indicated address. 
If the value is undefined, the routine branches to 
location DMSLSBB, where the constant is added to a 
string of constants that are to be defined later. 


8. The routine again decrements the byte count of 
information on the RLD card and tests the result for 
zero. If the result is zero, go to operation 2. 
Otherwise, processing continues in this routine. 


9. The routine next checks the continuation flag, a part 
of the data placed on the RLD card by the assembler. 
If the flag is on, the routine repeats its processing 
for a new address only--the processing is repeated from 
operation 4. If the flag is off, the routine repeats 
its processing for a new symbol--the processing is 
repeated from operation 2. 


Exits 
This routine exits to location RD in the initial and resume 
loading routine. 


END CARD ROUTINE - C6AA1 


Function 
This routine saves the END card address under certain 
circumstances and initializes the loader to load another 
control segment. 


Entry 
This routine has one entry point, C6AAl. The routine is 
entered from the RLD card routine. 


Operation 


1. This routine begins its operation with a test of card 
type. If the card being processed is not an END card, 
the routine branches to the LDT card routine. 
Otherwise, processing continues in this routine. 


2. The routine then determines whether the END card 
contains an address. If the card contains no address; 
the routine performs operation 7, below. Otherwise, the 
routine performs operation 3. 
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of IBM 


The routine next checks the end-address-saved switch. 

If this switch is on, an address has already been 

saved, and the routine performs operation 7. If the 
switch is off, the routine performs operation 4. ) 


The routine determines whether loading is absolute or 
relocated. If the loading process is absolute, the 
routine performs operation 6. Otherwise, the routine 
performs operation 5. 


The routine links to the REFADR routine to obtain the 
current relocation factor, and the routine adds this 
factor to the card-specified address. 


The routine stores the address (absolute or relocated) 
in area BRAD for possible use at the end-of~load 
transfer of control to the problem program. 


Goes to location PASSTWO Cin RLD routine) to process 
RLD cards. 


The routine then clears the ESID table, sets the 
absolute load flag on, and branches to the location 
specified in a general register (see "Exits"™). 


This routine exits to the location specified in a general 
register. This may be either of two locations: 


1. 


Location RD in the initial and resume loading routine. 
This exit occurs when the END card routine is 
processing an END card. 


The location in the LDT card routine, that is specified 

by that routine's linkage to the END card routine. 

This exit occurs when the LDT card routine entered this 

routine to clear the ESID table and set the absolute 

load flag on. j 


CONTROL CARD ROUTINE - CTLCRD1 


Function 


This routine handles the ENTRY and LIBRARY control cards. 


Entry 


This routine has one entry point, CTLCRDL. The routine is 
entered from the LDT card routine. 


Operations 


l. 
2. 


The CMS function SCAN is called to parse the card. 


If the card is not an ENTRY or LIBRARY card, the 
routine determines whether the NOINV option (no 
printing of invalid card images) was specified. If 
printing is suppressed, control passes to RD in the 
initial and resume loading routine, where another card 
is read. If printing is not suppressed, control passes 
to the disk and type output routine (DMSLIO), where the 
invalid card image is printed in the load map. If the 
card is a valid control card, processing continues. 


ENTRY Card 


If the ENTRY name is already defined in REFTBL, its 
REFTBL address is placed in ENTADR. Otherwise, a new 
entry is made in REFTBL, indicating an undefined 
external reference (to be resolved by later input or 
library search), and this REFTBL entry's address is 


placed in ENTADR. 

> 
The control card is printed by calling DMSLIO via 
CTLCRD; it then exits to RD. 
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IBRARY Card 


5. Only nonobligatory reference LIBRARY cards are handled. 
Any others are considered invalid. 


6. Each entry-point name is individually isolated and is 
searched for in the REFTBL. If it has already been 
loaded and defined, nothing is done and the next 
entry-~point name is processed. Otherwise, the 
nonobligatory bit is set in the flag byte of the REFTBL 
entry. 


7. Processing continues at operation 4. 


REFADR ROUTINE (DMSLDRB) 


Function 
This routine computes the storage address of a given entry 
in the reference table. 


Entry 
This routine has one entry point, REFADR. The routine is 
entered for several of the routines within the loader. 


Operation 


1. Checks to see if requested ESDID is zero. If so», uses 
LOCCNT as requested location and branches to the return 
location + 44. Otherwise, continues this routine. 


2. The routine first obtains, from the indicated ESID 
table entry, the position (n) of the given entry within 
the reference table (where the given entry is the nth 
REFTBL entry). 


3. The routine then multiplies n by 16 Cthe number of 
bytes in each REFTBL entry) and subtracts this result 
from the starting address of the reference table. The 
starting address of the reference table is held in area 
TBLREF. This address is the highest address in 
storage, and the reference table is always built 
downward from that address. 


4. The result of the subtraction in operation 2, above, is 
the storage address of the given reference table entry. 
If there is no ESD for the entry, goes to operation 5. 
Otherwise, this routine returns to the location 
specified by the calling routine. 


5. Adds an element to the chain of waiting elements. The 
element contains the ESD data item information to be 
resolved when the requested ESDID is encountered. 


PRSERCH ROUTINE (DMSLDRD) 


Function 
This routine compares each reference table entry name with 
the given name determining (1) whether there is an entry 
aa that name and (2) what the storage address of that 
entry is. 


Entry 
This routine is initially entered at PRSERCH and 
subsequently at location SERCH. The routine is entered 
from several routines within the loader. 


Operation 
1. This routine begins its operation by obtaining the 


number of entries currently in the reference table 
(this number is contained in area TBLCT), the size of a 


Processing and Executing CMS Files 77 


Licensed Material--Property of IBM 


LOADER DATA BASES 


ESIDTB ENTRY 


reference table entry (16 bytes), and the starting 

address of the reference table Calways the highest 

address in storage, contained in area TBLREF). : 
) 


2. The routine then checks the number of entries in the 
reference table. If the number is zero, the routine 
performs operation 5. Otherwise, the routine performs 
operation 3. 


3. The routine next determines the address of the first 
Cor next) reference table entry to have its name 
checked, increments by one the count it is keeping of 
name comparisons, and compares the given name with the 
name contained in that entry. If the names are 
identical, PRSERCH branches to the location specified 
in the routine that linked to it. PRSERCH then returns 
the address of the REFTBL entry. Otherwise, PRSERCH 
performs operation 4. 


4. The routine then determines whether there is another 
reference table entry to be checked. If there is none, 
the routine performs operation 5. If there is another, 
the routine decrements by one the number of entries 
remaining and repeats its operation starting with 
operation 3. 


5. If all the entries have been checked, and none contains 
the given name for which this routine is searching, the 
routine increments By one the count it is keeping of 
name comparisons, places that new value in area TBLCT, 
moves the given name to form a new reference table 
entry, and returns to the calling program. 


Exits 
This routine exits to either of two locations, both of 
which are specified by the routine that linked to this 
routine. The first location is that specified in the event 
that an entry for the given name is found; the second JZ 
location is that specified in the event that such as entry 
15 not found. 


ESD Card Codes (col. 25...) 
Code Meaning 


00 SD CCSECT or START) 
01 LD CENTRY) 

02 ER CEXTRN) 

04 PC (Private code) 

05 CM CCOMMON) 

06 XD (Pseudo-regi ster) 
OA WX CWEAK EXTERN) 


The ESD ID table CESIDTB) is constructed separately for each 
text deck processed by the loader. The ESIDTB produces a 
correspondence between ESD ID numbers Cused on RLD cards) and 
entries in the loader reference table (REFTBL) as specified by 
the ESD cards. Thus, the ESIDTB is constructed while processing 
the ESD cards. It is then used to process the TXT and RLD cards 
in the text deck. 


The ESIDTB is treated as an array and is accessed by using the 
ID number as an index. Each ESIDTB entry is 16 bits long. 2 
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Bits Meaning 


0 If 1, this entry corresponds to a CSECT that has been 
previously defined. All TXT cards and RLD cards referring 
to this CSECT in this text deck should be ignored. 


If 1, this entry corresponds to a CSECT definition (SD). 
Waiting ESD items exist for this ESDID. 
Unused. 

-15 REFTBL entry number (for example 1, 2, 3, etc.) 


BONE 


Bit 1 is very crucial because it is necessary to use the VALUE 
field of the REFTBL if the ID corresponds to an ER, CM, or PR; 
but, the INFO field of the REFTBL entry must be used if the ID 
corresponds to an SD. 


0¢0) 
NAME 


8(8) 909) 
FLAG INFO 


12(C) hee 


NOTE1 VALUE 


16(10) 17(€11) 
FLAG2 ADDRESS 


A REFTBL entry is 20 bytes. The fields have the following uses: 


NAME 
Contains the symbolic name from the ESD data item. 


FLAG1 


Loader ESD Routine 
code Code Label Meaning 


7C 00 XBYTE PR - byte alignment 

7D 01 XHALF PR - halfword alignment 
7E 03 XFULL PR - fullword alignment 
7F 07 XDBL PR - doubleword alignment 
80 05 XUNDEF Undefined symbol 

8l 04 XCXD Resolve CXD 

&2 02 XCOMSET Define common area 

83 05 WEAKEXT Weak external reference 
90 06 CTLLIB TXTLIBs not to be used to 


resolve names 


INFO 
Depends upon the type of the ESD item. 
ESD Item Type INFO Field Meaning 
SD CCSECT or START) Relocation 
factor 
LD CENTRY) Zero 
CM CCOMMON) Maximum length 


PR (Pseudo Register) - 
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VALUE 
Depends upon the type of the ESD item, as does the INFO 


fiel ) 
ESD Item Type INFO Field Meaning 
SD CCSECT or START) Absolute address 
LD CENTRY) Absolute address 
CM CCOMMON) Absolute address 
PR (Pseudo register) Assigned value (starting 
from 0) 
FLAG2 
Bit Meaning 
0 Unused 
l Unused 
2 Unused 
3 Unused 
4 Unused 
5 Name was located in a TXTLIB 
6 Section definition entry 
7 Name specifically loaded from command 
line. 
ADDRESS 
Unused 


Entries may be created in the loader reference table prior to 

the actual defining of the symbol . For example, an entry is 

created for a symbol if it is referenced by means of an EXTRN 

CER) even if the symbol has not yet been defined or its type 

known. Furthermore, COMMON (CM) is not assigned absolute 
eoctes es until prior to the start of execution by the START 
command. 3 


These circumstances are determined by the setting of the flag 
byte. If the symbol's value has not yet been defined, the value 
field specifies the address of a patch control block (PCB). 


PATCH CONTROL BLOCK (PCB) 


These are allocated from free storage and pointed at from REFTBL 
entries or other PCBs. 


Byte Meaning 


0-3 Address of next PCB 
4 Flag byte 
5-7 Location of ADCON in storage 


All address constant locations in loaded program for undefined 
symbols are placed on PCB chains. 


LOADER INPUT RESTRICTIONS 


All restrictions that apply to object files for the OS linkage 
editor apply to CMS loader input files. 


OADING AND EXECUTING MEMBERS OF LOADLIBS 


The 0S relocating loader support consists of two members: the 

relocating program (DMSLOS) and the overlay program (DMSSFF). 

In addition, the OSRUN command (DMSOSR) allows the user to 

invoke directly from the console a program residing in a CMS 
LOADLIB or an OS module library. DMSOSR executes in user 

storage. 
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When a user program invokes the LINK, LOAD, XCTL, or ATTACH SVC, 
DMSSLN calls DMSLOS to search the libraries in the LOADLIB 
global list for the specified member name. If found, DMSLOS 
loads and relocates the requested program from either an 0S 
module library (for example, SYS1.LINKLIB) or a CMS LOADLIB 
(created by the LKED command). If the member is not found, 
return is made to DMSSLN to search for a TEXT file or a member 
of a TXTLIB by that name. 


The program exists in the library as text records, directly 
followed Cwhen required) by control, relocation, and position 
records. DMSLOS obtains, via the BLDL macro, the information 
necessary to start loading the program from the PDS directory 
entry for the program. Then, text records and control records 
are read alternately, the proper addresses are modified, and 
return is made to DMSSLN. 


The OSRUN command generates a LINK SVC and therefore follows the 
same path described in the preceding paragraphs. However, if 
the requested member is not found in searching the libraries 
specified in the LOADLIB global list, a search is made for a 
default library ($SYSLIB LOADLIB); TEXT files and TXTLIB members 
are not searched. 


For detailed information on the library record formats, see the 


IBM OS/VS Linkage Editor Logic. 
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CE G COMMANDS THA THE FILE SYSTEM 


C 


Figure 39 on page 39 lists the CMS modules that perform either 


general file system support functions or that perform data 
manipulation. 
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MANAGING THE CMS FILE SYSTEM 


C 


A description of the structure of the CMS file system and the 
flow of routines that access and update the file system follows. 


DISK ORGANIZATION 


CMS virtual disks Calso referred to as minidisks) are blocks of 
data designed to externally parallel the function of real disks. 
Several virtual disks may reside on one real disk. 


A CMS virtual machine may have up to 26 virtual disks accessed 
during a terminal session, depending on user specifications. 
Some disks, such as the S-disk, are accessed during CMS 
initialization. However, most disks are accessed dynamically as 
they are needed during a terminal session. 


0 MS FILE RE ORGANIZED IN STORAGE FO OO-BYTE RECORD 


CMS files are organized in storage by three types of data 
blocks: the file status table (FST), chain links, and file 
records. Figure 14 shows how these types of data blocks relate 
to each other. The following text and figures describe these 
relationships and the individual data blocks in more detail. 


FILE STATUS TABLES 


CMS files consist of 8&00-byte records whose attributes are 
described in the file status table (FST). Tha file status table 
is defined by DSECT FSTSECT. The FST consists of such 

& information as the filename, filetype, and filemode of the file, 
the date on which the file was last written, and whether the 
file is in fixed-length or variable format. Also, the FST 
contains a pointer to the first chain link. The first chain 
link is a block that contains addresses of the data blocks that 
contain the actual data for the file. 


The FSTs are grouped into 800-byte blocks called FST Blocks 
(these are sometimes referred to in listings as hyperblocks). 
Each FST block contains 20 FST entries, each describing the 
attributes of a separate file. Figure 15 on page 8&6 shows the 
structure of an FST block and the fields defined in the FST. 


File Status 
Master Table Block File Status First Chain Nth Chain 
File Directory (FSTB) Table Entry Link (FCL) Link (NCL) 


a ot 


Address of 
FSTB Addr 
FCL Address of 
an 800-byte 
CMS Record 


= 800-byte CMS Record Containing File Data Items = 


C Figure 14. How 800-Byte CMS File Records are Chained Together 
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CHAIN LINKS 


CMS RECORD FORMATS 


Fields in a File Status Table Entry 


File Status 
Table Block 


FST 1 


FST 2 


16 
DATE LAST WRITTEN 
Write Pointer Read Pointer 
(Number of Item) (Number of Item) 
Disk Address of 
re Chain: ak pan Variable ae Byte 
Item Length (F) 
Maximum Item Length (V) 
71 36 Number of 


Figure 15. Format of a File Status Table Block - Format of a 
File Status Table. (for 800-Byte Disk Format) 


FST 20 


Chain links are 200- or 800-byte blocks of storage that chain 
the records of a file in storage. There are two types of chain 
links: first chain links and Nth chain links. 


The first chain link points to two kinds of data. The first 80 
bytes of the first chain link contain the halfword addresses of 
the remaining 40 chain links used to chain the records of thea 
file. The next 120 bytes of the file are the halfword addresses 
of the first 60 records of the file. 


The Nth chain links contain only halfword addresses of the 
records contained in the file 


Because there are 41 chain links Cof which the first contains 
addresses for only 60 records), the maximum size for any CMS 
file is 16,060 800-byte records. 


CMS records are 800-byte blocks containing the data that 
comprises the file. For example, the CMS record may contain 
several card images or print images, each is referred to as a 
record item. Figure 16 on page 87 shows how chain links are 
chained together. 
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CMS records can be stored on disk in either fixed-length or 
variable-length format. However, the two formats may not be 
mixed in a single file. 


Regardless of their format, the items of a file are stored by 
CMS in sequential order in as many 800-byte records as are 
required to accommodate them. Each record (Cexcept the last) is 
completely filled and items that begin in one record can end on 
the next record. Figure 17 on page 88 shows the arrangement of 
records jin files containing fixed-length records and files 
containing variable-length records. 


Disk Address of 2nd Chain Link 


Disk Address of 3rd Chain Link 
e Chain 
e Linkage 


Directory 


Disk Address of A + Oth Data Block 
Disk Address of A+ 1st Data Block 
e 
@ 
e 
Disk Address of A + 398th Data Block 
Disk Address of A+ 399th Data Block 


A=(n~-2) * 400 + 61 
where n = Chain Link Number 


e 
Disk Address of 40th Chain Link 
Disk Address of 41st Chain Link 
Disk Address of 1st Data Block 
Disk Address of 2nd Data Block 

e 

e 

e 
Disk Address of 59th Data Block 
Disk Address of 60th Data Block 


Figure 16. Format of the First Chain Link and Nth Chain Links 
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800 


| 


Figure 17. 


Data block structure 


for file Data block structure for file 


consisting of fixed-length records consisting of variable-length records 


1st record 


1st record 


800 800 8 pam----o-n-ro 


800 800 


4th record 


800 800 


Arrangement of Fixed-Langth Records and Variable-~Length Records in Files 


The location of any item ina file containing fixed-length 
records is determined by the formula: 


Citem number - 1) x record length 
locations = --9 o-oo ro oo rrr rr rrr rrr ee 


where the quotient is the sequential number of the data block 
and the remainder is the displacement of the item into the data 
block. 


For variable-length records, each record is preceded by a 2-byte 
field specifying the length of the record. 


PHYSICAL ORGANIZATION OF VIRTUAL DISKS 


Virtual disks are physically organized in 800-byte records. 
Records 1 and 2 of each user disk are reserved for IPL. Record 3. 
contains the disk label. Record 4 contains the master file 
directory. The remaining records on the disk contain user 
file-related information such as the FSTs, chain links, and the 
individual file records discussed above. 


THE MASTER FILE DIRECTORY 


The master file directory (MFD) is the major file management 
table for a virtual disk. As mentioned earlier, it resides on 
cylinder 0, track 0, record 4 of each virtual disk. The master 
file directory contains six types of information: 


e The disk addresses of the FST entries describing user files 
on that disk. 


e A 4-byte "sentinel,”™ which can be either FFFD or FFFF. FFFD 
specifies that extensions of the QMSK (described below) 
follow. FFFF specifies that no Q@MSK extensions follow. 

° Extensions to the QMSK, if any. 


° General information describing the status of the disk: 
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ADTNUM -~- The total number of 800-byte blocks on the 
user's disk. 


ADTUSED ~-- The number of blocks currently in use on the 
disk. 


ADTLEFT -- Number of blocks remaining for use CADTNUM - 
ADTUSED). 


ADTLAST -- Relative byte address of the last record in 
use on the disk. 


ADTCYL -~- Number of cylinders on the user's disk. 


Unit Type -- A l-byte field describing the type of the 
disk: 07 for a 3340, 08 for a 2314, 09 for a 3330, OB 
for a 3350, OC for a 3375, OE for a 3380, FE for a 3370, 
and FF for a 3310. 


A bit mask called the QMSK, which keeps track of the 
status of the records on disk. 


Another bit map, called the QQMSK, which is used only 
for 2314 disks and performs a function similar to that 
of QMSK. 


Figure 18 shows the structure of the master file directory. 
Figure 14 on page 85 shows the relationship of the Master File 
Directory, which resides on disk, to data blocks brought into 
a tee dented file management purposes, for example, FSTs and 
chain links. 


Byte 


Byte 
Byte 
Byte 
Byte 
Byte 


332 —> 
ADTCYL 
384 —> 
uit -tvr 
600 —=—»> 


Disk Address of 2nd FST Block (if any) 
e 


e 
Disk Address of Nth FST Block (if any) 


Disk Address of 1st QMSK extension (if any) 
e 
e 


e 
Disk Address of Nth QMSK extension (if any) 


ADTNUM, ADTUSED, ADTLEFT, ADTLAST 
(4 bytes each) 


Not used (zero) 


First 215 Bytes of OMSK 


Entire 200~-Byte QQMSK Table 
(for 2314 only) 


Figure 18. Structure of the Master File Directory 
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QMSK for 2314 or 2319 —| |— 1 bit >| 1 bit QMSK for 3330 


C 
H | 1 bit 
os i 


where: 

= Cylinder 
{= Head 
R = Record 


Bit Value Meaning 
0 Block available 
1 Block in use 


Number of QMSK Extensions Number of Cylinders on Disk 
Required (if any) | 23140r2319 | 3330 


140 — 182 


Figure 19. Disk Storage Allocation Using the QMSK Data Block 


KEEPING TRACK OF READ/WRITE DISK STORAGE: QMSK AND QQMSK 


Because CMS does not require contiguous disk space, disk space 
management needs to determine only the availability of &00-byte 
blocks and to chain them together. The status of the blocks on 
any read/write disk Cwhich blocks are available and which are 
currently in use) is stored in a table called QMSK. The term 
Q@MSK is derived from the fact that a 2311 disk drive has four 
800-byte blocks per track. One block is a "quarter-track,”™ or 
QTRK, and a 200-byte area is a "quarter-quarter-track,™ or 
QQTRK. The bit mask for 2314, 2319, 3319, 3330, 3340, 3350, 
3370, 3375, or 3380 records is called the QMSK, although each 
800-byte block represents less than a quarter of a track on 
these devices. 


On a 2314 or 2319 disk, the blocks are actually grouped fifteen 
800-byte blocks per even/odd pair of tracks. An even/odd pair 
of tracks is called a track group. On a 3330 disk, the blocks 
are grouped fourteen 800-byte blocks per track. On a 3340 disk, 
the blocks are grouped into eight 800-byte blocks per track. 


When the system is not in use, a user’s QMSK resides on the 
Master File Directory. During a session it is maintained on 
disk, but also resides in main storage. QMSK is of variable 
length, depending on how many cylinders exist on the disk. 


Each bit is associated with a particular block on the disk. The 


first bit in QMSK corresponds to the first block, the second bit 
to the second block, and so forth, as shown in Figure 19. 
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When a bit in QMSK is set to 1, it indicates that the 
corresponding block is in use and not available for allocation. 
A O-bit indicates that the corresponding block is available. 
The data blocks are referred to by relative block numbers 
throughout disk space management, and the disk I/0 routine, 
DMSDIO, finally converts this number to a CCHHR disk address. 


A table called QQMSK indicates which 200 byte segments (QQTRK) 
are available for allocation and which are currently in use. 
Q@QMSK contains 100 entries, which are used to indicate the 
status of up to 100 QQTRK records. An entry in QQMSK contains 
either a disk address, pointing to a QQTRK record that is 
available for allocation, or zero. QQMSK is used only for 2314 
files; for 3330, 3340, and 3350, the first chain Link occupies 
the first 200-byte area of an 800-byte block. 


The QMSK and QQMSK tables for read-only disks are not brought 
into storage, since no space allocation is done for a disk while 
it is read-only. They remain, as is, on the disk until the disk 
is accessed as a read/write disk. 


DYNAMIC STORAGE MANAGEMENT: ACTIVE DISKS AND FILES 


CMS disks and files contained on disk are physically mapped 
using the data blocks described above: for disks, the MFD, the 
QMSK, and the QQMSK; for files, the FST, chain links, and 
800-byte file records. In storage, all of this data is accessed 
by means of two DSECTs whose addresses are defined in the DSECT 
NUCON, ADTSECT and AFTSECT. 


Managing Active Disks: The Active Disk Table 


The ADTSECT DSECT maps information in the active disk table 
CADT). This information includes data contained in the MFD, FST 
blocks, the QMSK, and Q@QMSK. The DSECT comprises of ten 
"slots,™ each representing one CMS virtual disk. A slot 
contains significant information about the disk such as a 
pointer to the MFD for the disk, a pointer to the first FST 
block, and pointers to the QMSK and QQMSK, if the disk is a R/W 
disk. ADTSECT also contains information such as the number of 
cylinders on the disk and the number of records on the disk. 


Managing Active Files: The Active File Table 


Each open file is represented in storage by an active file table 
CAFT). The AFT Cdefined by the AFTSECT DSECT) contains data 
found on disk in FSTs,» chain links, and data records. Also 
contained in the AFT is information such as the address of the 
first chain link for the file, the current chain link for the 
file, the address of the current data block and the fileid 
information for the file. Figure 3 on page 6 shows the 
relationship between the AFT and other CMS data blocks. 


CMS ROUTINES USED TO ACCESS THE FILE SYSTEM 


DMSACC is the control routine used to access a virtual disk. In 
conjunction with DMSACM and DMSACF, DMSACC builds, in virtual 
storage, the tables CMS requires for processing files contained 
on the disk. The list below shows the logical flow of the main 
function of DMSACC. 


Access a Virtual Disk: DMSACC 
DMSACC 


Scans the command line to determine which disk is 
specified. 
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DMSLAD 
Looks up the address of the ADT for the disk specified on 
the command line. 


DMSACC 
Determines whether an extension to a disk has been 
specified on the command line and ensures that it is 
correctly specified. 


DMSLAD 
In the case where an extension has been specified, ensures 
that the extension disk exists. 


DMSLAD 
Ensures that the specified disk is not already accessed as 
a R/W disk. 


DMSFNS 
In the case where the specified disk is replacing a 
currently accessed disk, closes any open files belonging to 
the duplicate disk. 


DMSACC 
Verifies the parameters remaining on the command line. 


DMSALU 
Releases any free storage belonging to the duplicate disk 
via a call to DMSFRE. Also, clears appropriate entries in 
the ADT for use by the new disk. 


DMSACM 
(Called as the first instruction by DMSACF) Reads from the 
Master File Directory, the QMSK, and the QQMSK for the 
specified disk. Also, DMSACM updates the ADT for the 
specified disk using information from the MFD. 


DMSACF 
Reads into storage all the FST blocks associated with the 
specified disk. 


DMSACC 
Handles error processing or processing required to return 
control to DMSINT. 


| HOW CMS FILES ARE ORGANIZED IN STORAGE FOR 512-, 1K-, 2K-, OR 4K-BYTE RECORDS ON 


DISK 


FILE STATUS TABLES 


CMS files are organized by three types of blocks; the file 
status table (FST), pointer blocks, and file records. Figure 20 
on page 93 shows how these types of blocks relate to each other. 
The following text and figures describe these relationships and 
the individual data blocks in more detail. 


CMS files consist of 512-, 1K-, 2K-, or 4K-byte CMS blocks whose 
attributes are described in the file status table (FST). The 
file status table is defined by DSECT FSTSECT. The FST consists 
of such information as the filename, filetype, and filemode of 
the file, the date on which the file was last written, and 
whether the file is tn fixed-length or variable format. Also, 
the FST contains a pointer to the highest level pointer block or 
only data block. If it is a pointer block, this block contains 
addresses of the next lower level pointer blocks or the data 
blocks that contain the actual data for the file. 


The FSTs are grouped into 512-, 1K-, 2K-, or 4K-byte CMS blocks 
called FST blocks (these are sometimes referred to in listings 
as hyperblocks). Each FST block contains 8, 16, 32, or 64 FST 
entries respectively Can FST is 64 bytes long), each describing 
the attributes of a separate file. Figure 21 on page 934 shows 
the structure of an FST block and the fields defined in the FST. 
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Highest Level 
File Status Pointer Block Lower Pointer Lower 
File Directory Table Entry (FOP) Block (LPB) Pointer Block 


LPB 
Addr 
P 
| FOP | ede Address of a 1K, 
2K, or 4K record 


Tren [von [en 
| 512-,1K-, 2K-, or 4K-byte Record 
Containing File Data Items 


{ Figure 20. How 512-, 1K-, 2K-, or 4K-Byte CMS File Records are Chained Together 
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Fields in a File Status Table Entry 


Reserved 


File Status 
Table Block 


Reserved 


24 26 
Filemode Reserved 
28 30 31 
Reserved Fixed Variable Flag Byte 
=f Item Length (F) 
Maximum Item Length (V) 
36 
Reserved 
40 
File Origin Pointer (FOP) 


Number of 512, 1K, 2K, 4K Blocks 


48 
Number of Items In File 
52 53 54 


Highest Level Pointer Date Last Written 
of Pointer Entry 
Blocks Size 


(YY MM DD HH MM SS) 


| 60 
Reserved 


Figure 21. Format of a File Status Table Block ~ Format of a 
ute Status Table. (For 512-, 1K-, 2K-, 4K-Byte Disk 
ormat) 


POINTER BLOCKS 


Pointer blocks are 512-, 1K-, 2K-, or 4K-byte blocks of storage 
that chain the records of a file. There are up to five levels 
of pointer blocks. All but the first level of pointer blocks 
contain the fullword disk address of the next lower level 
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pointer block. The level-one pointer blocks contain the 
fullword disk addresses of the data blocks of the file (see 
Figure 22 on page 96 and Figure 23 on page 97). 


There are two types of pointer blocks: pointer blocks for fixed 
files which are as described above, and pointer blocks for 
variable files. For the variable files, each pointer block entry 
is three fullwords long. The first fullword holds the disk 
address of the next lower level pointer block, the next fullword 
holds the highest item number contained in this lower 
corresponding pointer block, and the last fullword holds the 
displacement, at the data level, to the first identified item 
contained in a lower corresponding pointer block. CMS blocks 
are not shared by files. 


Each entry of a level-one pointer block is composed of one 
fullword containing the disk address of the corresponding data 
block, one fullword containing the highest item number contained 
in this data block, and one fullword containing the 
displacement, in bytes, of the first identified item Cif any) 
contained in this data block. This last fullword of the entry 
may hold the hexadecimal value X'FF...F', indicating that the 
item is spanned. 


The last fullword of a pointer block holds the displacement, in 
bytes, of the last used entry, if one exists, in the block. 

This structure permits the creation of very large files. The 
maximum number of data blocks available in a variable format 
file on a lK-, 2K-, or 4K-byte blocksize minidisk is about 27! - 


1. The maximum number of data blocks available in a variable 
format file on a 512-byte blocksize minidisk is about 15 times 
less than 23! - 1. The maximum number of blocks available ina 


variable format file is 64K. 


Each pointer block or data block is prefixed in virtual storage 
with a header. This header holds an entry called DCHTRUNK that 
points to the upper level pointer block. Associated with the 
DCHTRUNK value is a displacement that indicates the 
corresponding entry in this upper level pointer block. 


In virtual storage, each level of pointer block and the data 


block have an anchor in the corresponding Active File Table 
CAFT) and are forward and backward chained by the prefix. 
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P3(0) 


Level 3 Pointer Block 
Disk Address P2(0) 4 
Disk Address P2(1) 


|__| 


P1(0) P1(1) P1(259) 


Disk Address DB(0) Disk Address DB(256) Disk Address DB(66304) 
Disk Address DB(1) Disk Address DB(257) Disk Address DB(66305) 
Level 1 


Pointer 
Blocks 


P2(0) P2(1) 


be 


Blocks 


DB(3) DB(66305) 


DB(1) 
= 


Item 


LJ 


Figure 22. Format of Level 3 Pointer Block Fixed-Length Record File 
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P2(0) 


Disk Address P1(0) 


Level 2 
Pointer 
Block 


1K +d125 


Level 1 


Pointer 
Blocks 
Data Block Data Block Data Block Data Block Data Block 
DB(O) DB(1) DB(92) DB(86) DB(87) 
d1 
ae a2 
d4 | Item 3 di25 | Item 124 
en ci 
Item 6 eecooece50e 
Item 4 L126 
Item 126 
. 


| 


re 


C Figure 23. Format of Level 2 Pointer Block Variable-Length Record File 
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CMS BLOCK FORMATS 


CMS blocks are 512-, 1K-, 2K-, or 4K-byte disk records 
containing the data that comprises the file. For example, the 
CMS record may contain several card images or print images, each 
of which is referred to a record item. Figure 22 on page 96 
shows how pointer blocks are chained together. 


CMS file items can be stored on disk in either fixed-length or 
variable-length format. However, the two formats may not be 
mixed ina single file. 


Regardless of their format, the items of a file are stored by 
CMS in sequential order in as many 512-, 1K-, 2K-, or 4K-byte 
records as are required to accommodate them. Each CMS block 
Cexcept the last) is completely filled and items that begin in 
one CMS block can end in the next CMS block. Figure 22 on page 
96 shows the arrangement of items in files containing 
fixed-length items and files containing variable-length items. 


The location of any item ina file containing fixed-length items 
is determined by the formula: 


Citem number - 1) x record length 
location = ------- o-oo oo 
512, lk, 2K, or 4K 


where the quotient is the sequential number of the data block 
and oe remainder is the displacement of the item into the data 
block. 


For variable-length files, each item is preceded by a 2-byte 
field specifying the length of the item. 


PHYSICAL ORGANIZATION OF VIRTUAL DISKS 


THE FILE DIRECTORY, 


Virtual disks are physically organized in 512-, 1K-, 2K~-, or 
4K-byte disk records. Records 1 and 2 of each user disk are 
reserved for IPL. Record 3 contains the disk label. The first 
block of the file directory is alternately exchanged between 
record 4 and record 5 when the directory is rewritten to disk. 
The remaining records on the disk contain information such as 
allocation map blocks, FSTBs, pointer blocks, and the individual 
file records as discussed above. 


CMS disk structures that reside on FB-512 devices are 5l2-, 
1024-, 2048-, or 4096-byte CMS block format. The required 
number of 512-byte physical FB-512 disk records are logically 
concatenated together to form each CMS block. For example; ona 
1024-byte format disk, FB-512 physical record numbers 0 and 1 
Corigin 0) are used together to form CMS block 1 Corigin 1). 

The FB-512 label occupies FB-51l2 block 1 Corigin 0) leaving CMS 
blocks 2 and 3 available for general use. 


THE ALLOCATION MAP, AND THE DISK LABEL 


The file directory and the allocation map have the same 
organization as files. The directory contains FSTs and the 
first block resides on cylinder 0, track 0, record 4 or record 5 
of each virtual disk. The record number (4 or 5) is maintained 
in the field disk origin pointer of the disk label. 


The directory itself is described by an FST that is the first 
FST in the first block. The filename for the directory is 
binary zero Cexcept for byte 4 which is binary 1), and the 
filetype is "DIRECTOR". 


The allocation map is described by an FST that is the second FST 
in the first block of the directory. The filename is binary 
zero Cexcept for byte 4 which is binary 2), and the filetype is 
TALLOCMAP™. 
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The disk label resides on cylinder 0, track 0, record 3. It is 
80-bytes long and contains the following information: 


ADTIDENT CMS1 is the label identifier. 


ADTID Six characters given by the user are the volume 
identifier. 


ADTDBSIZ One fullword; contains the disk block size that the 
user chooses at format disk time (512, IK, 2K, or 


GK). 
ADTDOP One fullword; contains records 4 or 5 depending upon 
the actual directory first data block address. 
ADTCYL One fullword; contains the number of formatted 
cylinders available for CMS files. 
ADTMCYL One fullword; contains the maximum number of 
formatted cylinders, that is, the size of the disk. 
ADTNUM One fullword; the total number of 512-, 1K~, 2K-, or 


&K-byte blocks on the user's disk. 


ADTUSED One fullword; the number of blocks currently in use 
on the disk. 


ADTFSTSZ One fullword; the size of the FST (64 bytes). 
ADTNFST One fullword; the number of FSTs per block. 


ADTCRED Six characters; the disk creation date 
CYYMMDDHHMMSS). 


KEEPING TRACK OF READ/HRITE DISK STORAGE: ALLOCATION MAP 


In CMS, disk space is composed of 512-, 1K-, 2K~-, or 4&K-byte 
blocks chained together. Because disk space management only 
determines the availability of blocks, not extents, it need not 
allocate disk space contiguously. The status of the blocks on 
any read/write disk (which blocks are available and which are 
currently in use) is stored in a table called the allocation 
map. The allocation map contains bits, each of which is 
associated with a particular CMS block. The first corresponds 
to the first CMS block, the second bit corresponds to the second 
CMS block, and so forth. 


When a bit in the allocation map is set to l, it indicates that 
the corresponding block is in use and not available for 
allocation. <A O-bit indicates that the corresponding block is 
available. The data blocks are referred to by relative block 
numbers through disk space management, and the disk I/0 routine, 
DMSDIO, finally converts this number to a CCHHR disk address or 
FB-512 block number. 


When the system is not in use, a user's allocation may resides 
on the corresponding disk. During a session, it is maintained 
on disk but also resides in real storage. The allocation map is 
variable in length, depending on how many cylinders exist on the 
disk. The CMS disk may reside on the entire physical disk pack 
and is limited only by the physical limit of the disk pack. 


A deallocation map exists in real storage when CMS disk blocks 
are deallocated. During a terminal session, a block is recorded 
as deallocated by turning on its corresponding bit in the 
deallocation map. 


When the disk is updated by rewriting the file directory and the 
allocation map, the current allocation map is formed by 
combining the allocation map and the deallocation map. In fact, 
a deallocation map block is created only for those allocation 
map blocks in which a CMS block is deallocated. 
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Selective Directory 


The allocation maps for read-only disks are not brought into 
storage because no space allocation is performed for a disk 

while it is in read-only status. They remain, as is, on the 
disk until the disk is accessed as a read-write disk. 


Update 


The file directory and the allocation map are built with CMS 
blocks (512-, IK-, 2K-, or 4K-bytes). The selective directory 
update function takes place when the file directory and the 
allocation map must be updated on the corresponding disk. It 
writes on disk only the modified blocks of the directory 
Cincluding required pointer blocks) and the entire allocation 
map. 


DYNAMIC STORAGE MANAGEMENT: ACTIVE DISKS AND FILES 


CMS disks are physically mapped in CMS blocks containing the 
file directory and the allocation map. CMS files on disk are 
mapped using FST blocks, pointer blocks, and 512-, IK-, 2K-, or 
4K-byte file data blocks. 


In real storage all of this data is accessed by means of two 
DSECTs whose addresses are defined in DMSNUC, ADTSECT, and 
AFTSECT. 10 ADTSECTs reside in DMSNUC and the others (ll 
through 26) reside in free storage when they are used. Five 
AFTs reside in DMSNUC and the others reside in free storage. 
(See Figure 24 on page 101.) 


Managing Active Disks: The Active Disk Table 


The ADTSECT DSECT maps information in the active disk table 
CADT). An ADT contains significant information about the CMS 
disk such as the anchors for pointer block levels, the data 
block for the file directory, and the data block for the 
allocation map Cif the disk is a read-write disk). The ADTSECT 
also contains disk label information. 


Managing Active Files: The Active File Table 


Each open file is represented in storage by an active file table 
CAFT). The AFT Cdefined by AFTSECT DSECT) contains data found 
on disk in FSTs, the anchors for pointer block levels and the 
data block for the file. The AFT also contains such information 
as the read pointer and write pointer of the file, the number of 
entries in a pointer block, the number of pointer block levels, 
and the length of a pointer block entry. Figure 24 on page 101 
shows the relationship between the AFT and other CMS blocks. 
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Figure 24 (Part 1 of 3). File System for 512-, 1K-, 2K-, or &K-Byte Record on Disk 
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Figure 24 (Part 2 of 3). File System for 512-, IK-, 2K-, or 4K-Byte Record on Disk 
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CMS ROUTINES USED TO ACCESS THE FILE SYSTEM 


DMSACC is the control routine used to access a virtual disk. In 
conjunction with DMSACM and DMSACF, DMSACC builds, in virtual 
storage, the tables CMS requires for processing files contained 
on the disk. The list below shows the logical flow of the main 
function of DMSACC. 


Access a Virtual Disk: DMSACC 


DMSACC 
Scans the command line to determine which disk is 
specified. 


DMSLAD 
Looks up the address of the ADT for the disk specified on 
the command line. 


DMSACC 
Determines whether an extension to a disk has been 
specified on the command line, and ensures that it is 
correctly specified. 


DMSLAD 
In the case where an extension has been specified, calls 
DMSLAD to ensure that the extension disk exists. 


DMSLAD 
Ensures that the specified disk is not already accessed as 
a R/W disk. 


DMSFNS 
In the case where the specified disk is replacing a 
currently accessed disk, closes any open files belonging to 
the duplicate disk. 


DMSACC 
Verifies the parameters remaining on the command line. 


DMSALU 
Releases any free storage belonging to the duplicate disk 
via a call to DMSFRE. Also, clears appropriate entries in 
the ADT for use by the new disk. 


DMSACM 
(Called as the first instruction by DMSACF) Reads from 
the file directory and the allocation map for the specified 
disk. Also, DMSACM updates the ADT for the specified disk 
using information from the file directory and disk label. 


DMSACF 
Reads into storage all the FST blocks associated with the 
specified disk. 


DMSACC 


Handles error processing or processing required to return 
control to DMSINT. 
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HANDLING I70 OPERATIONS 


CMS input/output operations for unit record, disk, and tape 
devices are always synchronous. 


Input/output operations to a card reader, card punch, or printer 
are initiated via a normal START I/0 instruction. After 
starting the operation, CMS enters the wait state until a device 
end interruption is received from the started device. Because 
the I/0 is spooled by CP, CMS does not handle any exceptional 
conditions other than not ready, end-of-file, or forms overflow. 


Disk and tape I/0 is initiated via a privileged instruction, 
DIAGNOSE, whose function code requests CP to perform necessary 
error recovery. Control is not returned to CMS until the 
operation is complete, except for tape rewind or rewind and 
unload operations, which return control immediately after the 
operation is started. No interruption is ever received as the 
result of DIAGNOSE I70. The CSW is stored only in the event of 
an error. 


CMS input/output operations to the terminal may be either 
synchronous or asynchronous. Output to the terminal is always 
asynchronous, but a program may wait for all terminal 
input/output operations to complete by calling the console wait 
routine. Input from the terminal is usually synchronous but a 
user may cause CMS to issue a read by pressing the attention 
key. A program may also asynchronously stack data to be read by 
calling the console attention routine. 


/0 PROCESSING 


Seven routines handle I/0 processing for CMS: DMSRDC, DMSPUN, 
and DMSPRT handle the READCARD, PUNCH, and PRINT commands and 
pass control to the actual I/0 processors, DMSCIO (for READCARD 
and PUNCH) or DMSPIO (for PRINT). DMSCIO and DMSPIO issue the 
SIO instructions that cause I/0 to take place. Two other 
routines, DMSIOW and DMSITI, handle synchronization processing 
for I/0 operations. Figure 25 on page 106 shows the overall 
flow of control for I/0O operations. 
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READ A CARD 


DMSRDC 
DMSPUN 
DMSPRT 


DMSPIO 
DMSIOW 
lL 


Figure 25. Flow of Control for Unit Record I/0 Processing 


The following are more detailed descriptions of the flow of 
control for the read, punch, and print unit record control 
functions. 


DMSRDC 
Initializes block length and unit record siza. 


DMSCIO 
Initializes areas to read records. 


DMSCIO 
Issues an SIO command to read a record. 


DMSIOW 


Sets the wait bit for the virtual card reader, and loads 
the I/0 old PSW from NUCON. This causes CMS to enter a 


wait state until the read I/O is complete. 


DMSITI 
Ensures that this interrupt is for the virtual reader. 


not, the I/0 old PSW is loaded, returning CMS to a wait 
state. If the interrupt is for the reader, DMSITI resets 


the wait bit in the I/0 old PSW and loads it causing 
control to return to DMSIOW. 


DMSIOW 


Places the symbolic name of the interrupting device in the 


PLIST, and passes control to the calling routine. 


DMSCIO 
Checks for SENSE information, and handles I/0 errors, 
necessary. 


DMSCWR 
Displays a control record at the console. 
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DMSSCN 
If another control record is encountered, formats it via 
DMSSCN. 


DMSCHR 
Displays the new control record at the console. 


DMSFNS 
Closes the file when end-of-file occurs. 


DMSRDC 
Issues a CP CLOSE command to close the card reader. 


DMSPUN 
Ensures that a virtual punch is available, and processes 
PUNCH command options. 


DMSSTT 
Verifies the existence of the file, and returns its 
starting address. 


DMSPUN 
If requested, sets up a header record, and calls DMSCWR to 
write it to the console. 


DMSBRD 
Reads a block of data into the read buffer, and continues 
reading until the buffer is filled. 


DMSBWR 
Writes a block of data on disk. 


DMSCIO 
Initializes areas to punch records. 


DMSCIO 
Issues the SIO instruction to punch the contents of the 
buffer. 


DMSCIO 
Issues a call to DMSIOW to wait for completion of the punch 
I/0 operation. 


DMSION 
Sets the wait bit on for the virtual punch device, and 
loads the I/0 old PSW from NUCON. This causes CMS to enter 
a wait state until the punch operation completes. 


DMSITI 
Ensures that this interrupt is for the punch. If not, the 
I70 old PSW is loaded returning CMS to a wait state. If the 
interrupt is for the punch, DMSITI resets the wait bit in 
So RNeTOnS” PSW and then loads the PSW, returning control 
oO : 


DMSIOW 
Places the symbolic name of the interrupting device in the 
PLIST, and passes control to DMSCIO. 


DMSCIO 
Checks for SENSE information, and handles I/O errors, if 
any. 


DMSPUN 
Handles error returns, and resets constants for the next 
punch operation. 


DMSFNS 


Closes the file, and returns control to the command 
handler, DMSINT. 
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PRINT A FILE 


DMSPRT ? 
Determines the device type of the printer. Checks out the 
specified fileid. Checks out the options specified on the 
PRINT command line, and calls DMSPIO to print the 
designated file. 


DMSSCN 
Verifies the existence of the file, and returns its 
starting address. 


DMSPRT 
Determines the record size to be printed, and sets up an 
appropriate buffer area via a call to DMSFRE. 


DMSFRE 
Obtains storage space to be used as a buffer. 


DMSPRT 
Determines whether the file to be printed is a library 
member or an input file. 


DMSBRD 
Reads a record; continues reading until the buffer is 
filled. When the buffer is filled, calls DMSPIO to issue 
the SIO instruction to begin the print operation. 


DMSPIO 
Builds appropriate printer CCW chain. Issues the print SIO 
instruction, and then calls DMSIOW to wait until the the 
I/0 operation completes. 


DMSIOW 
Sets the wait bit for the virtual printer device, and loads 
the I/0 old PSW from NUCON. This causes CMS to enter a 
wait state until the print operation completes. 


DMSITI 
Ensures that the interrupt is for the printer. If not, the 
I/0 old PSW is reloaded, returning CMS to a wait state. If 
the interrupt is for the printer, DMSITI resets the WAIT 
bit in the I/0 old PSW and loads that PSW, returning 
control to DMSIOW. 


DMSIOW 
Places the symbolic name of the device in the last word of 
the PLIST, and passes control to DMSPIO. 


DMSPIO 
Performs channel testing and handles errors. TIO 
instructions and sense SIO instructions are issued during 
the test processing. These operations are synchronized 
using DMSIOW and DMSITI in the manner described above. 
Serge I/0 completes successfully, control returns to 
DMSPRT. 


DMSPRT 
Determines whether all file records have been printed. If 
so, control returns to the caller. Otherwise, the address 
of the buffer is updated and more print operations are 
performed. 


Printer Carriage Control Characters Used by DMSPIO 


CMS supports the use of ASA control characters and machine 

carriage control characters for the printed output. Part of the 

CMS implementation depends upon the fact that the set of ASA 

control characters has almost nothing in common with the set of 

machine control characters. There are two exceptions to this, 

the characters X'Cl' and X‘'C3'. > 
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These two characters, when interpreted as ASA control 
characters, have the following meanings: 


Cl 
C3 


Skip to channel 10 before print. 


Skip to channel 12 before print. 


The same characters, when interpreted as machine control 
characters, have the following meanings: 


Cl 


Write, then skip to channel 8 after print. 
C3 = Do not write, but skip to channel 8 immediately. 


In printed lines containing carriage control characters, CMS can 
operate in two modes. In the first mode, ASA control characters 
or machines control characters are recognized and properly 
interpreted. However, two conflicting characters are always 
interpreted as ASA control characters. In the second mode» only 
machine control characters are recognized. Two conflicting 
characters are treated as machine control characters. 


The DMSPIO function uses a bit in the PLIST to indicate which of 
the two modes is in effect for printing. 


The PRINTL macro always uses ASA control character mode or 
machine control character mode. 


The PRINT command with the CC option always runs in ASA control 
character mode or machine control character mode. 


OS simulation output, which is used, for example, by the 
MOVEFILE command, uses the RECFM field in the DCB or in the 
FILEDEF command to determine which mode is to be used. If FA, 
VA, or UA is specified, then ASA control character mode or 
machine control character mode is used. If FM, VM, or UM is 
specified, then machine-~only mode is used. If no control 
character specification is included with the RECFM, then it is 
assumed that the output line begins with a valid data character 
rather than with a control character, and single spacing is 
always used. 


The CMS SETPRT command allows a CMS user to control the 
facilities of a virtual 3800 device defined for their virtual 
machine. The SETPRT command is similar in function to the 0S 
SETPRT macro. It allows the user to request multiple character 
arrangement tables, loading of copy modifications, etc. The 
command uses the current CMS search order for locating disk 
files. Therefore, users can create their own character 
arrangement tables, copy modifications, etc. and print files 
With user-defined characteristics. The SETPRT command writes 
3800 CCWs and data to a virtual 3800 spool file to set up the 
real 3800 for the data to follow. If a file is created ona 
virtual 3800 and printed on a real printer of a different type, 
the 3800 load CCWs imbedded within the file are ignored and 
printing takes place as normal. However, this may create output 
that does not appear as originally intended. 


The format of the command is: 
SETPRT CCHARS [C€] cece .... 


[COPIES [CJ] nnn [ 
[¢c COFYNR CC] nnn [ 


FLAsi id nn ()]] 
ODIFY [CC] mmmm [En] [)]] 
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DISK 170 IN CMS 


DMSSPR process the SETPRT command in the following manner: 


1. Accept input PLIST and analyze. If there are errors, issue 
a message to the user and exit. 


2. Select the correct character set modules, and load these 
modules into free storage. 


3. Assign writeable character generation modules (WCGMs), and 
change the translate tables if necessary. 


4. Issue SIOs to the virtual 3800 printer. In the case of an 
error, terminate processing, and issue a message and 
appropriate return code. 


5. Exit with a zero return code if the operation completes 
successfully. 


Files residing on disk are read and written using DMSDIO. 
DMSDIO has two entry points: DMSDIOR, which is entered for a 
read I/0 operation, and DMSDIOW, which is entered for a write 
operation. 


The actual disk I/0 operation is performed using the DIAGNOSE 
code 18 instruction. A return code of 0 from CP indicates a 
successful completion of the I/0 operation. If the I/O is not 
successful, CP performs error recording, retry, recovery, or 
ABEND procedures for the virtual machine. 


READ OR WRITE DISK If/0 


DMSDIO 
Initializes the CCW to perform read operations. 


DMSLAD 
Obtains the address of the disk from which to read or 
write. 


DMSDIO 
Determines the size of the record to be read or written. 


DMSFRE 


Gets enough storage to contain the record if the request is 


for a record longer than 800 bytes. 


DMSDIO 
Reads records continually until all records for the file 
have been read. 


DMSFRE 


Returns the buffer to free storage if the record was longer 


than 800 bytes. 


DMSDIO 
Returns to the caller. 


CMS TAPE LABEL PROCESSING 


DMSLBD 


Allows the user to specify tape label information that will 


be used by a program at execution time. 


DMSTLB 
Processes IBM standard tape labels for OS simulation, 
CMS/DOS, CMS commands, and the TAPESL macro. It also 
provides linkage to nonstandard user label routines for OS 
simulation and CMS commands. There are common tape label 
checking routines for input header and trailer labels and 
common tape label writing routines for output header and 
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trailer labels. These common routines are used for all IBM 
standard label processing regardless of what operating 
system is being simulated. 


DMSTIO 


Reads or writes a tape record. Also performs tape control 
operations. Functions by issuing diagnose code X'20'. 
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HANDLING INTERRUPTIONS 


C 


Figure 9 on page 39 lists the CMS modules that process 
interruptions for CMS. These CMS modules are described briefly 
in "Module Entry Point Directory." Also, see "Interrupt 
Handling in CMS." 
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Free storage can be allocated by issuing the GETMAIN or DMSFREE 
macros. 


Storage allocated by the GETMAIN macro is taken from the user 
program area, starting after the high address of the user 
program. Storage allocated by the DMSFREE macro can be taken 
from several areas. First, DMSFREE requests are allocated from 
the low-address free storage area. If requests cannot be 
satisfied from there, they are satisfied from the user program 
area. 


There are two types of DMSFREE requests for free storage: 
requests for user-type storage and nucleus~type storage, as 
specified in the TYPE parameter of the DMSFREE macro. These two 
types of storage are kept in separate areas. It is possible, if 
there are no 4K pages completely free in low storage, for 
storage of one type to be available in low storage, while no 
storage of the other type is available. 


ORAGE MANAGEMENT 


All GETMAIN storage is allocated in the user program area, 
starting after the end of the user's actual program. Allocation 
begins at the location pointed to by the NUCON pointer MAINSTRT. 
The location MAINHIGH, in NUCON, points to the highest address 
of GETMAIN storage. ; 


The STRINIT function initializes pointers used by CMS for 
simulation of 0S GETMAIN/FREEMAIN storage management. In the 
usual CMS execution environment, that is, when execution is 
initiated by the LOAD and START commands, CMS executes the 
STRINIT function as a part of the LOAD preparation for 
execution. In an OS environment established by CMS, such as 
OSRUN, the STRINIT function has already been executed and should 
not be done by the user program. In any case, the STRINIT macro 
should be issued only once in the OS environment preceding the 
initial GETMAIN request. 


The format of the STRINIT macro is: 


Clabel] STRINIT 
TYPCALL=|SVC 
ALR 


where: 


TYPCALL=/SVC 
BALR 


indicates how control is passed to DMSSTG, the routine that 
processes the STRINIT macro. Since DMSSTG is a 
nucleus~resident routine, other nucleus-resident routines 
can branch directly to it (TYPCALL=BALR). Routines that 
are not nucleus-~resident must use linkage SVC 
CTYPCALL=SVC). If no operands are specified, the default is 
TYPCALL=SVC. 


When the STRINIT macro is executed, both MAINSTRT and MAINHIGH 
are initialized to the end of the user’ S program, in the user 
program area. The end of the user's program is the upper 
boundary of the load module created by the CMS LOAD and INCLUDE 
commands. This upper boundary value is stored in the NUCON 
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field LOCCNT. When the user's program executes, the STRINIT 

macro is executed and the LOCCNT value is used to initialize . 
MAINSTRT and MAINHIGH. During the user program execution, the 

LOCCNT field is used in CMS to pass starting and ending , 
addresses of files loaded by OS simulation. (Reissuing the 

STRINIT macro during execution of an OS program or issuing the 

STRINIT macro without having done a CMS LOAD is not advised. 

The value in LOCCNT has not been appropriately set and this may 

cause a storage management failure.) As storage is allocated 

from the user program area to satisfy GETMAIN requests, the 

MAINHIGH pointer is adjusted upward. Such adjustments are 

always in multiples of doublewords, so that this pointer is 

always on a doubleword boundary. As the allocated storage is 

returned, the MAINHIGH pointer is adjusted downward. 


The pointer MAINHIGH can never be higher than FREELOWE. 

FREELOWE is the pointer to the lowest address of DMSFREE storage 
allocated in the user program area. If a GETMAIN request cannot 
be satisfied without extending MAINHIGH above FREELOWE, GETMAIN 
takes an error exit, indicating that insufficient storage is 
available to satisfy the request. 


The area between MAINSTRT and MAINHIGH may contain blocks of 
storage that are not allocated. Therefore, these blocks are 
available for allocation by a GETMAIN instruction. These blocks 
are chained together, and the first block is pointed to by the 
NUCON location MAINLIST. See Figure 4 on page 16 for a 
description of CMS virtual storage usage. 


The format of an element on the GETMAIN free element chain is as 
follows: 


FREPTR -- pointer to next free element in 
0(0) the chain, or 0 if there is no next 
element 


FRELEN -- length, in bytes, of this J 
4(4) element 


Remainder of this free element 


When issuing a variable-length GETMAIN, additional pages are 
reserved for CMS usage; this is a design value. A user who needs 
additional reserved pages (for example, for larger directories) 
should free up some of the variable GETMAIN storage from the 
high end. 


DMSFREE FREE STORAGE MANAGEMENT 
The DMSFREE macro allocates CMS free storage. The format of the 
DMSFREE macro is: 


Clabel] DMSFREE 


» AREA=|LOW » TYPCALL 
HIGH 
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where: 


label 
is any valid assembler language label. 


DWORDS={ n } 
£(0)} 


is the number of doublewords of free storage requested. 
DWORDS=n specifies the number of doublewords directly. 
DWORDS=(€0) indicates that register 0 contains the number of 
doublewords requested. 


MIN=€ n } 

€(1)} 

indicates a variable request for free storage. If the 
exact number of doublewords indicated by the DWORDS operand 
is not available, then the largest block of storage that is 
greater than or equal to the minimum is returned. MIN=n 
specifies the minimum number of doublewords of free storage 
directly. MIN=C€1) indicates that the minimum is in 
register 1. The actual amount of free storage allocated is 
returned to the requestor via general register 0. 


TYPE=|USER 
NUCLEUS 
indicates the type of CMS storage requested: USER or 
NUCLEUS. 


nana 


is the return address if any error occurs. "“laddr®™ is any 
address that can be referred to in an LA Cload address) 
instruction. The error return is taken if there is a macro 
coding error or if there is not enough free storage 
available to fill the request. If the asterisk (%) is 
specified for the return address, the error return is the 
same as a normal return. There is no default for this 

all If it is omitted and an error occurs, the system 
abends. 


AREA=|LOW 
HIGH 


indicates the area of CMS free storage from which this 
request for free storage is filled. LOW indicates any free 
storage below the user areas, depending on the storage 
requested. HIGH indicates DMSFREE storage above the user 
area. If AREA is not specified, storage is allocated 
wherever it is available. 


BALR 


indicates how control is passed to DMSFREE. Since DMSFREE 
is a nucleus-resident routine, other nucleus-resident 
routines can branch directly to it (TYPCALL=BALR). 

Routines that are not nucleus-resident must use linkage SVC 
CTYPCALL=SVC). 


The pointers FREEUPPR and FREELOWE in NUCON indicate the amount 
of storage that DMSFREE has allocated from the high portion of 
the user program area. These pointers are initialized to the 
beginning of the system loader tables. 


rvpoaLs [aye 


The pointer FREELOWE is the pointer to the lowest address of 
DMSFREE storage in the user program area. As storage is 
allocated from the user program area to satisfy DMSFREE 
requests, the pointer FREELOWE is adjusted downward. Such 
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adjustments are in multiples of 4K bytes so that this pointer is 

always on a 4K boundary. As the allocated storage is returned, 

this pointer is adjusted upward when whole 4K pages are ’ 
completely free. The freed pages are released by issuing a ) 
DIAGNOSE CODE X'10" instruction to CP. 


The pointer FREELOWE can never be lower than MAINHIGH. The 
MAINHIGH is the pointer to the highest address of GETMAIN 
storage. If a DMSFREE request cannot be satisfied without 
extending FREELOWE below MAINHIGH, then DMSFREE takes an error 
exit, indicating that insufficient storage is available to 
satisfy the request. Figure 4 on page 16 shows the relationship 
of these storage areas. 


The FREETAB free storage table is usually kept in nucleus low 
free storage. If there is no space available there, FREETAB is 
located from the top of the user program area. This table 
contains one byte for each page of virtual storage. Each such 
byte contains a code indicating the use of that page of virtual 
storage. The codes in this table are as follows: 


Code Meaning 


USERCODE (X'01') The page is assigned to user storage. 

NUCCODE (¢(X*'02') The page is assigned to nucleus storage. 

TRNCODE ¢(X*03') The page is part of the transient program area. 

USERCODE (X'04') The page is part of the user program area. 

SYSCODE (¢(X'05') The page is none of the above. The page 15 
assigned to system storage, system code, or the 
loader tables. 


Other DMSFREE storage pointers are maintained in the DMSFRT 
CSECT, tin NUCON. The four chain header blocks are the most 
important fields in DMSFRT. The four chains of unallocated 
elements are: 


The low storage nucleus chain » 
The low storage user chain 

The high storage nucleus chain 

The high storage user chain 


For each of these chains of unallocated elements, there is a 
control block consisting of four words with the following 
format: 


0€00)] POINTER -- pointer to the first free 
element on the chain, or zero, if the 
chain is empty. 


4°04) | NUM ~~ the number of elements on the 
chain. 


8(8)| MAX -- a value equal to or greater than 
the size of the largest free element on 
the chain. 


12¢€)}; FLAGS~ SKEY —- TCODE - Unused 


Flag Storage FREETAB 
byte key code 
where? 
POINTER 


points to the first element on this chain of free elements. 
If there are no elements on this free chain, then the 
POINTER field contains all zeros. 


NUM 
contains the number of elements on this chain of free | 
elements. If there are no elements on this free chain, 
then this field contains all zeros. 
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MAX 
is used to avoid searches that will fail. It contains a 
number not exceeding the size, in bytes, of the largest 
element on the free chain. Thus, a search for an element 
of a given size Will not be made if that size exceeds the 
MAX field. However, this number may actually be larger 
than the size of the largest free element on the chain. 


FLAGS 
The following flags are used: 


FLCLN (X'80') - Clean-up flag. This flag is set if the 
chain must be updated. This is necessary in the 
following circumstances: 


e If one of the two high-storage chains contains a 4K 
page that is pointed to by FREELOWE, that page can 
be removed from the chain, and FREELOWE can be 
increased. 


e All completely unallocated 4K pages are kept on the 
user chain, by convention. Thus, if one of the 
nucleus chains (Clow-storage or high-storage) 
contains a full page, then this page must be 
transferred to the corresponding user chain. 


FLCLB (€X'40') - Clobbered flag. This flag is set if 
the chain has been destroyed. 


FLHC (X'20') - High-storage chain. This flag is set 
for both the nucleus and user high-storage chains. 


FLNU (X"'10') - Nucleus chain. Set for both the low 
storage and high storage nucleus chains. 


FLPA (X'08') - Page available. This flag is set if 
there is a full 4K page available on the chain. This 
flag may be set even if there is no such page 
available. 


SKEY 
is a one-byte field that contains the storage key assigned 
to storage on this chain. 


TCODE 
is a one-byte field that contains the FREETAB table code 
for storage on this chain. 

Each element on the free chain has the following format: 
<eeeeeSCO+*SGG:s«CébytecS 


POINTER -- pointer to the next element 
in the free chain 


SIZE -- size of this free element, in 
bytes 


Remainder of this free element 


When the user issues a variable length GETMAIN, the control 
program reserves 6 1/72 pages for CMS usage; this is a designed 
and set value. If the user wants more space, (for example, for 
more directories) the user should free some of the variable 
GETMAIN area from the high end. 


As indicated in the illustration above, the POINTER field points 
to the next element in the chain, or contains the value zero if 
there is no next element. The SIZE field contains the size of 
this element, in bytes. 
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All elements within a given chain are chained together in order 
of descending storage address. This is done for two reasons: 


1. Because the allocation search is satisfied by the first free J 
element that ts large enough, the allocated elements are 
grouped together at the top of the storage area, and prevent 
storage fragmentation. This is particularly important for 
high-storage free storage allocations, because it is 
desirable to keep FREELOWE as high as possible. 


2. If free storage does become somewhat fragmented, the search 
causes as few page faults as possible. 


As a matter of convention, completely nonallocated 4K pages in 
high storage are kept on the user free chain rather than the 
nucleus free chain. This is because requests for large blocks 
of storage are made, most of the time, from user storage rather 
than from nucleus storage. Nucleus requests need to break up a 
full page less frequently than user requests. 


METHOD OF OPERATION FOR DMSFREE 


A description of the algorithms that allocate and release blocks 
follows. The descriptions are based on the assumption that 
neither AREA=LOW nor AREA=HIGH was specified in the DMSFREE 
macro call. If either was specified, then the algorithm must be 
appropriately modified. 


ALLOCATING USER FREE STORAGE 


When DMSFREE with TYPE=USER (the default) is called, the 
following steps are taken to satisfy the request. AS soon as 
one of the following steps succeeds, then user free storage 
allocation processing terminates. 


1. Search the low~-storage user chain for a block of the 
required size. 


2. Search the high-storage user chain for a block of the 
required size. 


3. Extend high-storage user storage downward into the user 
program area, modifying FREELOWE in the process. 


4. For fixed requests, there is nothing more to try. For 
variable requests, DMSFRE puts all available storage in the 
user program area onto the high-storage user chain, and then 
allocates the largest block available on either the 
high-storage user chain or the low-storage user chain. The 
allocated block is not satisfactory unless it is larger than 
the minimum requested size. 


ALLOCATING NUCLEUS FREE STORAGE 
When DMSFREE with TYPE=NUCLEUS is called, the following steps 
are taken in an attempt to satisfy the request, until one 


succeeds: 


1. Search the low-storage nucleus chain for a block of the 
required size. 


2. Search the high~storage nucleus chain for a block of the 
required size. 


3. Get free pages from the high-storage user chain, if they are 
available, and put them on the high-storage nucleus chain. 


4. Extend high~storage nucleus storage downward into the user 
program area, modifying FREELOWE in the process. 
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5. For fixed requests, there is nothing more to try. For 
variable requests, DMSFRE puts all available pages from the 
high-storage user chain and the user program area onto the 
high-storage nucleus chain, and allocates the largest block 
available on either the low-storage nucleus chain or the 
high-storage nucleus chain. 


The DMSFRET macro releases free storage previously allocated 
with the DMSFREE macro. 


The format of the DMSFRET macro is: 


Clabel] DMSFRET 


where: 


label 
is any valid Assembler language label. 


elas Fn 


Paedes 
(1) 


pore] fro 


DHORDS= BP Peoe 


is the number of doublewords of storage to be released. 
DWORDS=n specifies the number of doublewords directly. 
DWORDS=(0) indicates that register 0 contains the number of 
doublewords being released. 


boc tegen 
is the address of the block of storage being released. 
"laddr™ is any address that can be referred to in an LA 
(load address) instruction. LOC=laddr specifies the 


address directly. LOC=(1) indicates the address is in 
register l. 


we coal 
% 


is the return address if an error occurs. “laddr™ is any 
address that can be referred to by an LA (load address) 
instruction. The error return is taken if there 15 a macro 
coding error or if there is a problem returning the 
storage. If an asterisk (*%) is specified, the error return 
address is the same as the normal return address. There is 
no default for this operand. If it is omitted and an error 
occurs, the system abends. 


TYPCALL=iSVC 
BALR 


indicates how control is passed to DMSFRET. Since DMSFRET 
is a nucleus-resident routine, other nucleus-resident 
routines can branch directly to it (TYPCALL=BALR). 

Routines that are not nucleus-resident must use SVC linkage 
CTYPCALL=SVC). 


When DMSFRET is called, the block being released is placed on 
the appropriate chain. At that point, the final update 
operation 1s performed, if necessary, to advance FREELOWE, or to 
ae pages from the nucleus chain to the corresponding user 
chain. 


Managing CMS Storage 121 


Licensed Material--Property of IBM 


Similar update operations are performed, when necessary, after 
calls to DMSFREE, as well. When FREELOWE is adjusted upward, 
the corresponding pages are released by issuing a DIAGNOSE code 
X'10" instruction to CP. 


RELEASING ALLOCATED STORAGE 


STORAGE ALLOCATED BY GETMAIN 


Storage allocated by the GETMAIN macro may be released in either 
of the following ways: 


e A specific block of such storage may be released by means of 
the FREEMAIN macro. 


e Whenever any user routine or CMS command abends (so that the 
routine DMSABN is entered) and the ABEND recovery facility 
of the system is invoked, all GETMAIN storage area pointers 
are reset. 


STORAGE ALLOCATED BY DMSFREE 


Storage allocated by the DMSFREE macro may be released in any of 
the following ways: 


° A specific block of such storage may be released by means of 
the DMSFRET macro. 


e Whenever any user routine or CMS command abnormally 
terminates (so that the routine DMSABN is entered) and the 
abend recovery facility of the system is invoked, all 
DMSFREE storage with TYPE=USER is released automatically. 


Except in the case of abend recovery, storage allocated by the 
DMSFREE macro is never released automatically by the system. 
Thus, storage allocated by means of this macro should always be 
released explicitly by means of the DMSFRET macro. 

DMSFREE SERVICE ROUTINES 


The system uses the DMSFRES macro to request certain free 
storage management services. 


The format of the DMSFRES macro is: 


Clabel] DMSFRES 
» TYPCALL=) SVC 
ALR 


where: 


label 
is any valid Assembler language label. 


INITL 
invokes the first free storage initialization routine, to 
allow free storage requests to access the system disk. 
Before INIT1 is invoked, no free storage requests may be 
made. After INIT1 has been invoked, free storage requests 
may be made. However, these requests are subject to the 
following restraints until the second free storage 
management initialization routine has been invoked: 
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e All requests for user-type storage are changed to 
requests for nucleus-type storage. 


e Error checking is limited before initialization is 
complete. In particular, it is sometimes possible to 
release a block that was never allocated. 


e All requests that are satisfied in high storage must be 
temporary, because all storage allocated in high 
storage is released when the second free storage 
initialization routine is invoked. 


When CP's saved system facility is used, the CMS system is 
saved at the point after the system disk has been accessed. 
It is necessary for DMSFRE to be used before the size of 
virtual storage is known, because the saved system can be 
used on any size virtual machine. Thus, the first 
initialization routine initializes DMSFRE so that limited 
functions can be requested. The second initialization 
routine performs the initialization necessary to allow the 
full functions of DMSFRE to be exercised. 


invokes the second initialization routine. This routine is 
invoked after the size of virtual storage is known, and it 
performs initialization necessary to allow all the 
functions of DMSFRE to be used. The second initialization 
routine performs the following steps: 


e Releases all storage that has been allocated in the 
high-storage area. 


e Allocates the FREETAB free storage table. This table 
contains one byte for each 4K page of virtual storage, 
and so cannot be allocated until the size of virtual 
storage is known. It is allocated in the nucleus low 
free storage area, if there is enough room available. 
If not, then it is allocated in the higher free storage 
area. For a 256K virtual machine, FREETAB contains 64 
eee for a 16 million byte machine, it contains 4096 

ytes. 


e The FREETAB table is initialized, and all storage 
protection keys are initialized. 


invokes a routine that checks all free storage chains for 
consistency and correctness. Thus, it checks to see 
whether any free storage pointers have been destroyed. 
This option can be used at any time for system debugging. 


turns ona flag that causes the CHECK routine to be invoked 
each time a call is made to DMSFREE or DMSFRET. This can 
be useful for debugging purposes (for example, when you 
wish to identify the routine that destroyed free storage 
management pointers). Care should be taken when using this 
option, since the CHECK routine is coded to be thorough 
rather than efficient. Thus, after the CKON option has 
been invoked, each call to DMSFREE or DMSFRET takes much 
longer to be completed than before. This can impact the 
efficiency of system functions. 


CKOFF 


UREC 


turns off the flag that was turned on by the CKON option. 


is used by DMSABN during the abend recovery process to 
release all user storage. 


CALOC 


is used by DMSABN after the abend recovery process has been 
completed. It invokes a routine that returns, in register 
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0, the number of doublewords of free storage that have been 
allocated. This number is used by DMSABN to determine 
whether the abend recovery has been successful. 


TYPCALL=|SVC 
BALR 


indicates how control is passed to DMSFRES. Since DMSFRES 
is a nucleus-resident routine, other nucleus-resident 
routines can branch directly to it (CTYPCALL=BALR). 

Routines that are not nucleus-resident must use SVC linkage 
CTYPCALL=SVC). 


STORAGE PROTECTION KEYS 


In general, the following rule for storage protection keys 
applies: system storage is assigned the storage key of X'FO!, 
while user storage 1s assigned the key of X'EO". This is the 
storage key associated with the protected areas of storage, not 
ee be confused with the PSW or CAW key used to access that 
storage. 


The specific key assignments are as follows: 
€ The NUCON area is assigned the key of X'FO", with the 


exception of the last page containing the OPSECT and 
TSOBLOKS areas and user free storage, which have a key of 


X"EO". 

e Free storage allocated by DMSFREE is broken up into user 
storage and nucleus storage. The user storage has a 
protection key of X'E0", while the nucleus storage has a key 
of X'FO’. 

° The transient program area has a key of X‘'EO’. 

° The CMS nucleus code has a storage key of X‘'FO’. In saved 


systems, this entire segment is protected by CP from 
modification even by the CMS system, and so must be entirely 
reentrant. 


° The user program area is assigned the storage key of X'EO0', 
except for those pages which contain nucleus DMSFREE 
storage. These latter pages are assigned the key of X'‘'FQO'. 


° The loader tables are assigned the key of X'FO". 


CMS HANDLING OF PSW 


KEYS 


The CMS nucleus protection scheme protects the CMS nucleus from 
inadvertent destruction by a user program. This mechanism, 
however, does not prevent you from writing in system storage 
intentionally. Because you can execute privileged instructions, 
you can issue a LOAD PSW CLPSW) instruction and load any PSW key 
you wish. If this occurs, there is nothing to prevent your 
program from: 


° Modifying nucleus code 
e Modifying a table or constant area 
e Losing files by modifying a CMS file directory 


In general, user programs and disk-resident CMS commands are 
executed with a PSW key of X'E’", while nucleus code is executed 
with a PSW key of X'O0". 


There are, however, some exceptions to this rule. Certain 
disk-resident CMS commands run with a PSW key of X'O0", because 
they have a constant need to modify nucleus pointers and 
storage. The nucleus routines called by the GET, PUT, READ, and 
WRITE macros run with a user PSW key of X'E* to increase 
efficiency. 
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Two macros, DMSKEY and DMSEXS, are available to any routine that 
wishes to change its PSW key. 
C THE DMSKEY MACRO 
The DMSKEY macro may be used to change the PSW key to the user 


value or the nucleus value. The format of the DMSKEY macro is: 


Clabel] DMSKEY {NUCLEUSE,NOSTACK] | 
USERL ,NOSTACK] | 


LASTUSERL ,NOSTACK] | 
RESET} 


where: 


NUCLEUS 
causes the nucleus storage protection key to be placed in 
the PSW, and the old contents of the second byte of the PSW 
is saved in a stack. This option allows the program to 
store into system storage, which is ordinarily protected. 


USER 
causes the user storage protection key to be placed in the 
PSW, and the old contents of the second byte of the PSW is 
saved ina stack. This option prevents the program from 
inadvertently modifying nucleus storage, which is 
protected. 

LASTUSER 


The SVC handler traces back through its system save areas 
for the active user routine closest to the top of the 
stack. The storage key in effect for that routine is 
placed in the PSW. The old contents of the second byte of 
the PSW is saved ina stack. This option should be used 

YL only by system routines that should enter a user exit 
routine. (0S macro simulation routines use this option 
when they want to enter a user-supplied exit routine. The 
exit routine is entered with the PSW key of the last user 
routine on the SVC system save area stack.) 


NOSTACK 
This option may be used with any of the above options to 
prevent the system from saving the second byte of the 
current PSW in a stack. If this is done, then no DMSKEY 
RESET need be issued later. 


RESET 
The second byte of the PSW is changed to the value at the 
top of the DMSKEY stack, and removed from the stack. Thus, 
the effect of the last DMSKEY NUCLEUS, DMSKEY USER, or 
DMSKEY LASTUSER request is reversed. However, if the 
NOSTACK option was specified on the DMSKEY macro, the RESET 
option should not be used. A DMSKEY RESET macro must be 
executed for each DMSKEY NUCLEUS, DMSKEY USER, or DMSKEY 
LASTUSER macro that was executed and that did not specify 
the NOSTACK option. Failure to observe this rule results 
in program abnormal termination. CMS requires that the 
DMSKEY stack must be empty when a routine terminates. 


THE DMSEXS MACRO 


The DMSEXS, “execute in system mode," macro is useful in 
situations where a routine is being executed with a user PSW 
key, but wishes to execute a single instruction with a nucleus 
PSW key. The single instruction may be specified as the 
argument to the DMSEXS macro, and that instruction is executed 
with a nucleus PSW key. This macro can be used instead of two 
DMSKEY macros. 
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The format of the DMSEXS macro is: 


The op-code and the operands of the instruction to be executed 
must be given as arguments to the DMSEXS macro. 


For example, execution of the sequence, 


USING NUCON,0O 
DMSEXS O1,0SSFLAGS,COMPSWT 


causes the OI instruction to be executed with a zero protect key 
in the PSW. This sequence turns on the COMPSWT flag in the 
nucleus. It is reset with 


DMSEXS NI,OSSFLAGS,255-COMPSNT 
The instruction to be executed may be an EX instruction. 


Register 1 cannot be used in any way in the instruction being 
executed. 


Whenever possible, CMS commands are executed with a user protect 
key. This protects the CMS nucleus in cases where there is an 
error in the system command that would otherwise destroy the 
nucleus. If the command must execute a single instruction or 
small group of instructions that modify nucleus storage, then 
the DMSKEY or DMSEXS macros are used, so that the system PSW key 
is used for as short a period of time as is possible. 


CP HANDLING FOR SAVED SYSTEMS 


The explanation of saved system nucleus protection depends on J 
the VSK, RSK, VPK and RPK: 


1. Virtual Storage Key C(VSK) - This is the storage key assigned 
by the virtual machine using the virtual SSK instruction. 


2. Real Storage Key (RSK) - This is the actual storage key 
assigned by CP to the 2K page. 


3. Virtual PSW Key (VPK) - This is the PSW storage key assigned 
by the virtual machine, by means of an instruction such as 
LPSW CLoad PSW). 


4. Real PSW Key CRPK) - This is the PSW storage key assigned by 
CP, which is in the real hardware PSW when the virtual 
machine is running. 


When there are no shared segments in the virtual machine, 
storage protection works as it does on a real machine. RSK=VSK 
for all pages,» and RPK=VPK for the PSW. 


However, when there is a shared segment (as in the case of the 
CMS nucleus), it is necessary for CP to protect the shared 
segment. For non-CMS shared systems, CP protects the shared 
segment by ignoring the values of the VSKs and VPK and assigning 
the real values as follows: RSK=0 for each page of the shared 
segment, RSK=F for all other pages, and RPK=F, always, for the 
real PSW. The SSK instruction is ignored, except to save the 
key value in a table in case the virtual machine later does an 
ISK to get it back. 


For the CMS saved system, the RSKs and RPK are initialized as 
before, but resetting the virtual keys has the following 


effects: ) 
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e If the virtual machine uses an SSK instruction to reset a 
VSK, CP does the following: If the new VSK is nonzero, CP 
resets the RSK to the value of the VSK; if the new VSK is 
zero, CP resets RSK to F. 


° If the virtual machine uses a LPSW Cor other) instruction to 
reset the VPK, CP does the following: If the new VPK is 
non-zero, CP resets the RPK to the value of the VPK; if the 
new VPK is zero, CP resets RPK to F. 


° If the VPK=0 and the RPK=F, storage protection may be 
handled differently. In a real machine, a PSW key of 0 
would allow the program to store into any storage location, 
no matter what the storage key. But under CP, the program 
gets a protection violation, unless the RPK of the page 
happens to be F. 


Because of this, there is extra code in the CP program check 
handling routine. Whenever a protection violation occurs, 
CP checks to see if the following conditions hold: 


= The virtual machine running is the saved CMS system, 
running with a shared segment. 


_ The VPK = 0. The virtual machine is operating as though 
its PSW key is 0. 


_ The RSK of the page where the store was attempted is 
nonzero, and different from the RPK. 


If any one of these three conditions fails to hold, then the 
protection violation is reflected back to the virtual machine. 


If all three of these conditions hold, then the RPK Cthe real 
protection key in the real PSW) is reset to the RSK of the page 
where the store was attempted. 


In CMS, this works as follows: CMS keeps its system storage in 
eee aan, F CRSK = VSK = F}, and user storage in protect key E 
C(RSK = VSK = E). 


When the CMS supervisor is running, it runs in PSW key 0 (VPK = 
0, RPK = F), so that CMS gets a protection violation the first 
time it tries to store into user storage (VSK = RSK = E). At 
that point, CP changes the RPK to E, and lets the virtual 
machine re-execute the instruction that caused the protection 
violation. There its not another protection violation until the 
supervisor goes back to storing into system-protected storage. 


There are several coding restrictions that must be imposed on 
CMS if it is to run as a saved system. 


The first and most obvious one is that CMS may never modify the 
segments containing CMS nucleus code that is shared and runs 
with a RSK of 0, although the VSK = F. 


A less obvious, but just as important, restriction is that CMS 
may never modify with a single machine instruction Cexcept MVCL) 
a section of storage that crosses the boundary between two pages 
with different storage keys. This restriction applies not only 
to $5 instructions, such as MVC and ZAP, but also to RS 
instructions, such as STM, and to RX instructions, such as ST 
and STD, which may have nonaligned addresses on the System/370. 
An exception is the MVCL instruction. This instruction can be 
restarted after crossing a page boundary because the registers 
are updated when the paging exception occurs. 
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This restriction also applies to I/O instructions. If the key 
specified in the CCW is zero, then the data area for input may 


nee cross the boundary between two pages with different storage 
eys. J 
OVERHEAD 
It can be seen that this system is most inefficient when 
"storage-key thrashing" occurs ~- when the virtual machine with 
: Mae of 0 jumps around, storing into pages with differant 
SK's. 


ERROR CODES FROM DMSFRES, DMSFREE, AND DMSFRET 


A nonzero return code upon return from DMSFRES, DMSFREE, or 
DMSFRET indicates that the request could not be satisfied. 
Register 15 contains this return code, indicating which error 
has occurred. The following codes apply to the DMSFRES, 
DMSFREE, and DMSFRET macros. 


Code Error 


1 (DMSFREE) Insufficient storage space is available to 
satisfy the request for free storage. In the case of a 
variable request, even the minimum request could not be 
satisfied. 

2 CDMSFREE or DMSFRET) User storage pointers destroyed. 

3 CDMSFREE, DMSFRET, or DMSFRES) Nucleus storage 
pointers destroyed. 

4 (DMSFREE) An invalid size was requested. This error 
exit is taken if the requested size is not greater than 
zero. In the case of variable requests, this error 
exit is taken if the minimum request is greater than 
the maximum request. (However, the latter error is not 
detected if DMSFREE is able to satisfy the maximum } 
request, ) 

5 (DMSFRET) An invalid size was passed to the DMSFRET 
macro. This error exit is taken if the specified 
length is not positive. 

6 CDMSFRET) The block of storage that is being released 
was never allocated by DMSFREE. Such an error is 
detected if one of the following errors is found: 


e The block does not lie entirely inside either the 
free storage area in low storage or the user 
program area between FREELOWE and FREEUPPR. 

e The block crosses a page boundary that separates a 
page allocated for user-type storage from a page 
allocated for nucleus-type storage. 

e The block overlaps another block already on the 
free storage chain. 


7 CDMSFRET) The address given for the block being 
released is not on a doubleword boundary. 

8 CDMSFRES) An invalid request code was passed to the 
DMSFRES routine. Since all request codes are generated 
by the DMSFRES macro, this error code should never 
appear. 

9 (DMSFREE, DMSFRET, or DMSFRES) An internal error 
occurred in the free storage management routine. 
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SIMULATING NON-CMS OPERATING ENVIRONMENTS 


The following contains descriptions for: access method support 
for non-CMS operating systems, CMS simulation of 0S functions, 
and CMS implementation of VSE functions. 


ACCESS METHOD SUPPORT FOR NON-CMS OPERATING ENVIRONMENTS 


OS ACCESS METHOD SUPPORT 


An access method governs the manipulation of data. To make the 
execution of OS generated code easier under CMS, the processing 
program must see data as 0S would present it. For instance, 
when the processors expect an access method to acquire input 
source records sequentially, CMS invokes specially written 
routines that simulate the OS sequential access method and 
passes data to the processors in the format that the 0S access 
methods would have produced. Therefore, data appears in storage 
as if it had been manipulated using an OS access method. For 
example, block descriptor words (BDW), buffer pool management, 
and variable records are maintained in storage as if an QS 
access method had processed the data. The actual writing to and 
reading from the I/0 device is handled by CMS file management. 


The work of the volume table of contents (VTOC) and the data set 
control block (DSCB) is done by a master file directory (MFD). 
The MFD maintains the disk contents and a file status table 
CFST) for each data file. All disks are formatted in physical 
blocks of 512, 800, 102%, 2048, or 4096 bytes. 


CMS continues to maintain the OS format, within its own format, 
on the auxiliary device for files whose filemode number is 4. 
That is, the block and record descriptor words (BDW and RDW) are 
written along with the data. If a data set consists of blocked 
records, the data is written to and read from the I/40 device in 
physical blocks, rather than logical records. CMS also 
simulates the specific methods of manipulating data sets. 


To accomplish this simulation, CMS supports certain essential 
macros for the following access methods: 


BDAM Cdirect) 
identifying a record by a key or by its relative position 
within the data set. 


BPAM Cpartitioned) 
seeking a named member within an entire data set. 


BSAM/QSAM Csequential) 
accessing a record in a sequence in relation to preceding 
or following records. 


VSAM Cdirect or sequential) 
accessing a record sequentially or directly by key or 
address. CMS support of OS VSAM files is based on 
VSE/VSAM. Therefore, the 0S user is restricted to those 
services available under VSE/VSAM. 


CMS SUPPORT FOR THE VIRTUAL STORAGE ACCESS METHOD 
CMS simulation of OS and DOS includes support for the virtual 
storage access method (VSAM). The description of this Support 
is in three parts: 
e A description of the access method services program 


CAMSERV), which allows you to create and update VSAM files. 
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e A description of support for VSAM functions under CMS/DOS. 


e A description of support for VSAM functions for the CMS OS 
simulation routines. 


J 


The routines that support VSAM reside in four discontiguous 
shared segments (DCSSs). 


= The CMSAMS DCSS, which contains the VSE/VSAM code to 
support AMSERV processing. 


= The CMSVSAM DCSS, which contains actual VSE/VSAM code, 
and the CMS/VSAM OS interface program for processing OS 
VSAM requests. 


- The CMSDOS DCSS, which contains the code that supports 
VSE requests under CMS. 


= The CMSBAM DCSS, which contains the SAM modules required 
for AMS to access SAM files. 


Note: DMSVSR, which performs completion processing for CMS/VSAM 
support, resides in the CMS nucleus. 


CREATING THE DOSCB CHAIN 


EXECUTING AN AMSERV 


The DLBL command creates a control block called a DOSCB in CMS 
free storage. The ddname specified in this DLBL command is 
associated with the ddname parameter in the program's ACB. 


The DOSCB contains information defining the file for the system. 

The information in the DOSCB parallels the information written 

on the label information area of a real DOS SYSRES unit; for 

example, the name, and mode (volume serial number) of the data 

set, its logical unit specification, and its data set type (SAM 

or al The anchor for this chain is at location DOSFIRST in 

NUCON. J 


FUNCTION 


The CMS AMSERV command invokes the module DMSAMS, which is the 
CMS interface to the VSE/VSAM access method services (AMS) 
program. Module DMSAMS loads VSE/VSAM AMS code, contained in 
the CMSAMS DCSS, by means of the LOADSYS DIAGNOSE 64. The AMS 
code requires the services of VSE/VSAM code that resides in the 
CMSVSAM DCSS. So, that DCSS is also loaded via LOADSYS DIAGNOSE 
64 when the VSAM master catalog is opened. Figure 26 on page 
131 shows the relationship in storage between the interface 
module DMSAMS, the CMSAMS DCSS, and the CMSVSAM DCSS. 
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CMS A-disk 
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1SYSLST ae 
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CMSVSAM DCSS or DOS User 


VSAM 
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Figure 26. Relationship in Storage between the CMS Interface 
Module DMSAMS, the CMSAMS DCSS, and the CMSVSAM DCSS 


Operation 


DMSAMS first determines whether the user is in the CMS/DOS 
environment. If not, a SET DOS ON CVSAM) command is issued to 
load the CMSDOS segment and to initialize the CMS/DOS 
environment. In this case, DMSAMS must also issue ASSGN 
commands for the disk modes in the DOSCB chain created by the OS 
user's DLBL commands. An ASSGN is also issued for SYSCAT;, the 
VSAM master catalog. 


DMSAMS then tissues the ASSGN command for the SYSIPT and SYSLST 
files, assigning them to the user's A-disk. DLBL commands are 
then issued associating these units with files on the user's 
A-disk. Input to the AMSERV processor is in the SYSIPT file. 
This file has the filetype AMSERV. Output from AMSERV 
processing is placed in the SYSLST file. This file has the 
filetype LISTING. 


DIAGNOSE 64 CLOADSYS}) is then issued to load the CMSAMS DCSS, 
which contains the VSE/VSAM code. A VSE SVC 65 is issued to 
find the address of the VSE/VSAM root phase, IDCAMS. When the 
SVC returns with the address of IDCAMS, a branch is made to 
IDCAMS, giving control to “"live™ VSE/VSAM routines. 


IDCAMS expects parameters to be passed to it when it receives 
control. DMSAMS passes dummy parameters in the list labeled 
AMSPARMS. 


After the root phase IDCAMS receives control, the functions in 
the is specified by the filename on the AMSERV command are 
executed. 
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In performing the functions requested in this file, AMS may 
require execution of VSE/VSAM phases located in the CMSVSAM 
DCSS. The CMSVSAM DCSS is loaded when AMS opens the VSAM 
catalog for processing. 


On return from VSE/VSAM code, DMSAMS purges the CMSAMS DCSS and 
issues DLBL commands for the SYSIPT and SYSLST files to clear 
the DOSCB’'s for these ddnames. 


Control is then passed to DMSVSR, which purges the CMSVSAM DCSS. 
If the user program was not in the CMS/DOS environment when 
DMSAMS was entered, the SET DOS OFF command is issued by DMSVSR. 
Upon return from DMSVSR, DMSAMS performs minor housekeeping 
tasks and returns control to CMS. 


J 


EXECUTING A VSAM FUNCTION FOR A VSE USER 


DOS VSAM Program 


OPEN ACB1 


CLOSE ACB1 


When a VSAM function, such as an OPEN or CLOSE macro, is 
requested from a VSE program, CMS routes control through the 
CMSDOS DCSS to the CMSVSAM DCSS, thus giving control to VSE/VSAM 
phases. Figure 27 shows the relationships in storage between 
the user program, the CMSDOS DCSS, and the CMSVSAM DCSS. The 
description below illustrates the overall logic of that control 
flow. ; 


CMSDOS DCSS DOS Transient Area CMSVSAM DCSS 


DMSDOS 
$$BOVSAM 


DMSBOP 


IKQVOPEN 


$$BCVSAM 


DMSCLS 


IKQVCLS 


$$BACLOS 


B-disk for OS 
or DOS User 


VSAM Master Catalog 


it 


Figure 27. The Relationship in Storage between the User Program, the CMSDOS DCSS, 
and the CMSVSAM DCSS 


CMS/DOS SVC Handling 


There are four CMS/DOS routines that handle VSAM requests: 
DMSDOS, DMSBOP, DMSCLS, and DMSXCP. Within DMSDOS, several SVC 
functions support VSAM requests. These are described in 
"Simulating a VSE Environment Under CMS." 
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DMSDOS VSAM PROCESSING: DMSDOS VSAM processing involves 
handling of SVC 65 C(CDLOAD), which returns the address of a 
specified phase to the caller. DMSDOS searches both the shared 
segment table and the nonshared segment table for the CMSDOS and 
CMSVSAM segments, because both could be in use. Both of these 
segment tables contain the name of each phase consisting of that 
segment followed by the fullword address of that phase within 
the segment. 


During SVC 65 processing, DMSDOS checks to see if the IJBLKMD is 
being requested. IJBLKMD is the VSE lookaside function that 
VSE/VSAM uses to gain information from the partition anchor 
tables. If this is the case, DMSDOS returns the address of the 
IJBLKMD that resides in the CMSBAM DCSS. 


If VSAM has not been loaded, a DIAGNOSE 64 CLOADSYS) is issued 
to load the CMSVSAM DCSS. 


DMSBOP VSAM PROCESSING: When DMSBOP is entered to process ACBs, 
it checks to see if CMSVSAM is loaded. If VSAM has not been 
loaded, DIAGNOSE 64 is issued to load the CMSVSAM DCSS. DMSBOP 
then initializes the transient work area and issues a VSE OPEN 
via SVC 2 to bring the VSAM OPEN S$S$BOVSAM transient into the VSE 
transient area. 


When VSAM processing completes, control returns to the user 
program directly. 


DMSCLS VSAM PROCESSING: DMSCLS processing is nearly the same as 
processing for DMSBOP. When DMSCLS is entered, it checks for an 
ACB to process. If there is one, the $$BCVSAM transient work 
area is initialized and SVC 2 is issued to FETCH the VSAM CLOSE 
transient S$$BCVSAM into the VSE transient area. When the VSAM 
CLOSE routines complete processing, control returns to the user 
program, as in the case of OPEN. 


Note: Since VSE does not support the 3380, CMS/DOS cannot 
access a 3380 when minidisks are formatted as OS/DOS disks. 


EXECUTING A VSAM FUNCTION FOR AN OS USER 


OS user requests for VSAM services are handled by VSE/VSAM code 
that resides in the CMSVSAM DCSS. To access this code, OS VSAM 
requests are intercepted by the CMS module DMSVIP. DMSVIP is 
the interface between the 0S VSAM requests and the CMS/DOS and 
VSE/VSAM routines. 


Because DMSVIP is in the CMSVSAM segment, it is available only 
when that segment is loaded. Module DMSVIB, which resides in 
the CMS nucleus, is a bootstrap routine to load the CMSVSAM 
segment and to pass control to DMSVIP. 


DMSVIP receives control from VSAM request macros in three ways: 

via SVC (for example, OPEN and CLOSE), via a direct branch using 

the address of DMSVIP in the ACB, and via a direct branch to the 

location of DMSVIP whose address is 256 bytes into the CMSCVT. 

erplearadl is a CMS control block that simulates the OS CYT control 
ock. 


This last technique is used by the code generated from the 05 
VSAM control block manipulation macros (GENCB, SHOWCB, TESTCB, 
MODCB). That is, the address at 256 into CVT is assumed to be 
the address of a control block that is at. displacement X'12' has 
the address of the VSAM control block manipulation routine. To 
ensure that DMSVIP receives control from these requests, the 
address of DMSVIP is stored at 256 bytes into CMSCVT. However, 
until the CMSVSAM segment is loaded, the address at CMSCVT+256 
is the address of module DMSVIB rather than the address of 
DMSVIP. The address of DMSVIP replaces that of DMSVIB when 
CMSVSAM is loaded. Both DMSVIB and DMSVIP have pointers to 
themselves at 12 bytes into themselves to ensure that this 
technique works. 
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Figure 28 on page 134 shows the relationships in storage between 
the user program, the OS simulation and interface routines, the 
CMSDOS DCSS, and the CMSVSAM DCSS. 


B-disk for OS 


OS VSAM CMS Module DOS Transient CMSVSAM or DOS User 


Program DMSSOP 


OPEN ACB 1 


CLOSE ACB 1 
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Figure 28. Relationship in Storage between the User Program, 0S Simulation and 
Interface Routines, CMSDOS DCSS, and CMSVSAM DCSS 


DMSVIP Processing 


Simulate an OS VSAM 


The following description illustrates the overall logic of that 
control flow. 


DMSVIP gains control from DMSSOP when an OS SVC 19, 20 or 23 
(CLOSE TYPE=T) is issued. It also gains control on return from 
execution of a VSAM function, as described below. DMSVIP 
performs five main functions: 


° Initializes the CMS/DOS environment for OS VSAM processing. 
e Simulates an OS VSAM OPEN macro. 
° Simulates an OS VSAM CLOSE macro. 


° Simulates an OS VSAM control block manipulation macro 
(GENCB, MODCB, SHOWCB, or TESTCB). 


° Processes OS VSAM I/0 macros. 


INITIALIZING THE CMS/DOS ENVIRONMENT FOR OS VSAM PROCESSING: 
DMSVIP gets control when the first VSAM macro is encountered in 
the user program. Initialization processing begins at this 
time. The CMSDOS DCSS is loaded by issuing the command SET DOS 
ON CVSAM). ASSGN commands are also issued at this time 
according to the user-~issued DLBL's indicated in the DOSCB 
chain. Once this initialization completes, DMSVIP processes the 
VSAM request. 


After the initialization, DMSVIP first checks to determine which 
VSAM function is being requested, OPEN, CLOSE, or a control 
block manipulation macro. 


OPEN 


For OPEN processing, the DOSSVC bit in NUCON is set on and 
control passes to DMSBOP via SVC 2. Once the CMS/DOS routines 
are in control, execution of the VSAM function is the same as 
the execution of the VSE/VSAM functions described above. 


On return from executing the OPEN routine, the address of 
another entry point to DMSVIP, at label DMSVIP2, is placed in 
the ACB for the data set just opened, the DOSSVC bit is turned 
off, and control is passed to DMSSOP, which returns to the user 
program. DMSVIP2 is the entry point for code that performs 
linkage to the VSAM data management phase IKQVSM. This is done 
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after the first OPEN because it is assumed that, once opened, 
the user performs I/0 for the phase; for example, a GET or PUT 
operation. 


When the linkage routine is entered, the DOSSVC bit is set on 
and control is given to the VSAM data management routine IKQVSM. 
On return from IKQVSM, DMSVIP turns off the DOSSVC bit and 
returns control to the user program. (Refer to "Simulate 0S 
VSAM I/O Macros" in this section.) 


CLOSE 


For CLOSE processing, the DOSSVC bit is set on and control is 
passed to the CMS/DOS routine DMSCLS via SVC 2. As in the case 
of OPEN, once control passes to the CMS/DOS routine, execution 
of the VSAM function is the same as the execution of the 
VSE/VSAM functions described above. 


On return from executing the VSAM CLOSE, the DOSSVC bit is 
turned off and control passes to DMSSOP, which returns to the 
user program. 


SIMULATE OS VSAM CONTROL BLOCK MANIPULATION MACROS: DMSVIP 
simulates the GENCB, MODCB, SHOWCB, and TESTCB control block 
manipulation macros. 


GENCB Processing: When a GENCB macro is issued with BLK=ACB or 
BLK=EXLST specified, the GENCB PLIST is passed unmodified to 
IKQGEN for execution. If GENCB is issued with BLK=RPL and 
ECB=address specified, the PLIST is rearranged to exclude the 
ECB specification, because CMS/DOS does not support ECB 
processing. The GENCB PLIST is then passed to IKQGEN for 
execution. 


MODCB, SHOWNCB, and TESTCB Processing: When MODCB, SHONCB, or 
TESTCB is issued, the OS ACB, RPL, and EXLST control blocks are 
reformatted, if necessary, to conform to VSE/VSAM formats. 


For MODCB and SHOWCB, the requests are passed to IKQTMS for 
processing. When MODCB is issued with EXLST= specified, ensure 
that the exit routines return control to entry point DMSVIP3. 


For TESTCB, check for any error routines the user may have 
specified. If the TESTCB specified RPL= and IO=COMPLETE, a not 
equal result is passed to the user. All other TESTCB requests 
are passed to DOS, and the new PSW condition code indicates the 
results of the test. 


If an error return 1s provided for TESTCB, the address of 
DMSVIP4 is substituted in the PLIST. This allows DMSVIP to 
regain control from VSAM so that the DOSSVC bit can be turned 
off. The error routine is then given control after the address 
is returned to the PLIST. 


SIMULATE OS VSAM I/G MACROS: DMSVIP simulates the OS GET, PUT, 
POINT, ENDRE@, ERASE, and CHECK I/0 macros. 


GET, PUT, POINT, ENDREQ, and ERASE Processing: First, the 0S 
request code in register 0 is mapped to a VSE request code. The 
RPL or chain of RPLs is rearranged to VSE format Cunless that 
has already been done). 


If there is an ECB address in the OS RPL, a flag is set in the 
new VSE RPL and the ECB address is saved at the end of the RPL. 


Asynchronous I/0 processing is simulated by setting active exit 
returns inactive in the user EXLST. The exception to this is 
the JRNAD exit. It need not be set inactive since it is not an 
error exit. Setting error exits to be inactive prevents VSAM 
from taking an error exit, thus allowing such an exit to be 
deferred until a CHECK can be issued for it. 


The VSE macro is then issued to IKQVSM via a BALR. 
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VSE error codes returned in the RPL FDBK field that do not exist 

in 0S are mapped to their OS equivalents. If the user has 

specified synchronous processing, this return code is passed , 
unchanged in register 15. ; 


For asynchronous processing, return codes are cleared before 
return and any exit routines set inactive are reactivated in the 
EXLST. Also, all ECBs are set to WAITING status. 


CHECK Processing: For CHECK processing, return codes in the RPL 
FDBK field are checked to determine the results of the I/0 
operation. If there is an active exit routine provided for the 
return code, control is passed to that routine. Also, all 
WAITING ECBs are posted with an equivalent completion code. 


If no active exit routine is provided or if the exit routine 
returns to VSAM, the return code is placed in register 15 and 
control is returned to the instruction following the CHECK. 


CMS/VSAM ERROR RETURN PROCESSING: Two types of support for 
error routine processing are provided in DMSVIP. Entry point 
DMSVIP3 provides support for user exit routines; entry point 
DMSVIP4% provides support for ERET error returns. 


User Exit Routine Processing: DMSVIP provides support for 05 
VSAM I/O error exits at entry point DMSVIP3. At this entry 
point the DOSSVC bit is turned off and the user storage key is 
restored. 


The address of the user routine is recovered from VIP's saved 
exit list Ceither the primary exit list in the work area or the 
overflow exit list, OEXLSA). 


Control then passes to the appropriate exit routine. If the 
routine is one that returns to VSAM, the DOSSVC flag is set ON 
and VSAM processing continues. 


DMSVIP can save the addresses of up to 128 exit routines during ) 
execution of a user program. 


ERET Error Routine Processing: DMSVIP provides support for 0S 
VSAM ERET exit routines used in conjunction with the TESTCB 
macro. This support is located at entry point DMSVIP4. At 
DMSVIP4, the DOSSVC bit is turned off and the user storage key 
is restored. The address of the ERET routine is recovered from 
the work area and control passes to that routine. 


The ERET routine may not return control to VSAM. 


Completion Processing for OS and VSE/VSAM Programs 


When an OS or VSE/VSAM program completes, control is passed to 
module DMSVSR, which "cleans up™ after VSAM. DMSVSR can be 
called from three routines after OS processing: 


DMSINT if processing completes without system errors or 
serious user errors. 


DMSEXT if the user program is used as part of an EXEC file. 


DMSABN if there are system errors or the user program 
abnormally terminates. 


After VSE/VSAM processing completes, DMSVSR is called by DMSDOS. 
DMSVSR issues an SVC 2 to execute the DOS transient routine 


SSBACLOS. $$BACLOS first checks for any OPEN VSAM files. If any 
are open, SVC 2 is issued to $$BCLOSE (CDMSCLS) to close the 


files. 
If there are no open files or if all ACB"s have been closed, > 
SSBACLOS issues SVC 2 to $SBE0J4, an entry point in DMSVSR. At 


SSBEOJ4, a PURGESYS DIAGNOSE 64 is issued to purge the CMSVSAM 
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DCSS. DMSVSR then checks to see if an OS program has completed 
processing. If this is the case, the SET DOS OFF command is 
issued and control returns to the caller. 


CMS QSA APE END-OF-VOLUME EXIT 


A program working with CMS simulation of 05 @SAM can set up an 
exit that could be entered on the end-of-volume condition on IBM 
standard label tapes. This exit receives control after the 
trailer labels have been processed and the tape has been rewound 
and unloaded. Without this exit, CMS terminates the program 
after the end-of-volume condition is reached. This exit should 
not be confused with the OS DCB end-of-volume exit. The OS DCB 
end-of-volume exit continues to be unsupported. 


TEOVEXIT MACRO 


Use the TEOVEXIT macro instruction to set up and clear a CMS 
tape end-of-volume exit. 


The four formats of the TEOVEXIT macro instruction are: 


standard 

MF=L 
MF=(L,addrl[,label]) 
MF=CE,addr) 


Standard Format 


The standard format of the TEOQVEXIT macro is: 


[label] TEOVEXIT SET, DDNAME={'ddname' |addr},EXIT=addr, 
RETINFO=addrl,ERROR=addr] } 
" CLR, DDNAME={' ddname' | addr} [,ERROR=addr] 


where: 


addr 
is an assembler program label or an address stored ina 
general register. If a register is used, it must be 
enclosed in parentheses. 


label 


is an assembler program label. 


SET 
establishes an exit. 


CLR 
clears an exit. 


DDNAME= 
is the "ddname” the tape end-of-volume exit is being 
established for. "ddname" may be from 1 to 8 alphameric 
characters enclosed in quotes. 


EXIT= 


label is an assembler program label that is the address 
of the program's end-of-volume processing routine. 


(Rn) is a general register. Its value is the address of 
the program's end-of-volume processing routine. 


( This routine receives control after trailer labels have 
been processed and the tape has been rewound and unloaded. 
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MF=L Format 


This routine receives control with the same PSW key as the 
call to CMS QSAM. The registers passed to the exit are the 
same as they were at the call to QSAM except: register 0 
points to the DCB; register 1 points to the FCB; register 
14 contains the address the routine branches to upon 
completion. If the exit does not return control to the 
address in register 14, future options are unpredictable 
for that file. Register 15 contains the address of the 
user exit routine. 


(This attribute is required for SET. If the EXIT attribute 
1s specified on CLR, it is ignored. No MNOTE is issued.) 


Note: When control is returned to the program that issued 
the QSAM call, the registers are unaffected by changes to 
registers in the end-of-volume exit. 


RETINFO= 
label 15 an assembler program label that is the address 
of a 20-byte halfword aligned area. 
(Rn) 1s a general register. Its value is the address of 


a 20-byte halfword aligned area. 


The program must provide this 20 byte, halfword aligned 
area for return information. 


(This attribute is required for SET. If the RETINFO 
attribute is specified on CLR, it iS ignored. No MNOTE is 
issued.) 


ERROR= 


label is an assembler program label that is the address 
of the error routine. 


(Rn) is a general register. Its value is the address of 
the error routine. 


The error routine receives control if an error is found. 
If this parameter is not specified and an error occurs, 
control returns to the next sequential instruction in the 
calling program. 


When MF=L is coded, the TEQVEXIT macro has the following format: 


[label] TEOVEXIT MF=L 
[,DDNAME='ddname'1[,EXIT=label] 
[,RETINFO=label] 
»SETC, DDNAME='ddname'][,EXIT=label] 
[,RETINFO=label] 
»CLRCL , DDNAME='ddname! ] 


All parameters have the same meaning as the standard format with 
the following difference: 


MF=L 
indicates that the parameter list is created in-line. No 
executable code is generated. Register notation cannot be 
used for macro parameter addresses. 


Note: When using the MF= parameter, all other parameters are 
optional. When the function is executed, however, a valid 
combination of parameters must have been specified by the LIST 
and EXECUTE formats of the macro. 
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MF=(L,addrl,labell) Format 


When MF=(L,addr[,label]) is coded, the TEOVEXIT macro has the 
( following format: 


[label] TEOVEXIT MF=(L,addrLl,label]) 
[, DDNAME={'ddname! | addr}] 
[,EXIT=addrJ[,RETINFO=addr] 


»SETLE, DDNAME={' ddname' | addr} ] 
[,EXIT=addrJC,RETINFO=addr] 
»CLRLE, DDNAME={'ddname’ | addr} ] 


All parameters have the same meaning as the standard format with 
the following difference: 


MF=(L,addrl[, label] )} 
indicates that the parameter list is created in the area 
specified by “addr”. The address -may represent an area 
within your program or an area of free storage obtained by 
a system service. You can determine the size of the 
parameter list by coding the "label" operand. The macro 
expansion equates "label" to the size of the parameter 
list. This format of the macro produces executable code to 
move the data into the parameter list specified by "addr". 
However, it does not generate the instructions to invoke 
the function. If this version of the LIST format is used, 
it must be executed before any related invocation of the 
EXECUTE format. 


Note: When using the MF= parameter, all other parameters are 
optional. When the function is executed, however, a valid 
combination of parameters must have been specified by the LIST 
and EXECUTE formats of the macro. 


VW 


MF=(E,addr) Format 


When ago Cerone! is coded, the TEOVEXIT macro has the following 
format: 


Clabel]J TEOVEXIT MF=CE,addr) 
C, DDNAME={'ddname' ] addr}1[,EXIT=addr] 
C,RETINFO=addrJ[,ERROR=addr] 


»SETZ, DDNAME={"ddname' | addr} 1[,EXIT=addr] 
C,RETINFO=addril,ERROR=addr] 
»CLRDE , DDNAME={'ddname' |addr} JL, ERROR=addr] 


All parameters have the same meaning as the standard format with 
the following difference: 


MF=(E,addr) 
indicates that instructions are generated to execute the 
TEOVEXIT function. "addr" represents the location of the 
parameter list. Information in the parameter list may be 
changed by specifying the appropriate operands on the 
macro. 


Note: When using the MF= parameter, all other parameters are 
optional. When the function is executed, however, a valid 
combination of parameters must have been specified by the LIST 
and EXECUTE formats of the macro. 
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RESTRICTIONS 


RETURN CODES 


SET Function: 


Tape end-of-volume exit only applies to CMS OS QSAM 
simulation. 


Only IBM standard label tapes are supported. If other than 
standard labels are used, you receive a return code of 16 
from TEOQVEXIT. 


The LEAVE option of the FILEDEF command is invalid. If it 
is used, you receive a return code of 20 from TEOVEXIT. 


The NOEOV processing option of the FILEDEF command is 
invalid. If it is used, you receive a return code of 28 
from TEOVEXIT. 


You cannot read backwards. If it is attempted, the results 
are unpredictable. 


The tape end-of-volume exit is not entered if either an OPEN 
or a CLOSE is in progress. 


The exit must not issue I/0 requests that might result in 
the tape end-of-volume exit being invoked. If it is 
attempted, the results are unpredictable. 


The exit must not issue additional QSAM requests to the 
file. If it is attempted, the results ara unpredictable. 


The exit must not modify or clear the FCB of the file the 
end-of-volume condition was encountered on. 


If any errors occur during the processing of tha TEOVEXIT macro, 
register 15 contains the error return codes. 


Code Meaning 


End-of-volume exit is established for the 
specified DDNAME. This is the normal return. 
The DDNAME specified is not found. (No 
FILEDEF was found with the given DDNAME. } 
Device specified in the FILEDEF is not a tape 
device. 

Tape identification is invalid. (Must be 
TAP], TAP2, TAP3, TAP4.) 

Tape label type is other than "SL". 

"LEAVE" is specified in the FILEDEF (FCB). 
Invalid PLIST. 

"NOEOV™ is specified in the FILEDEF CFCB). 
Exit address or RETINFO address is zero. 
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Code Meaning 


0 End-of-volume exit is cleared for the 
specified DDNAME. This is the normal return. 
A return code of 0 may also indicate the 
end-of-volume exit was not in effect, but it 
was still cleared. 


4 The DDNAME specified is not found. (No 
FILEDEF was found with the given DDNAME. 3) 
24 Invalid PLIST. 


SUCCESSFUL COMPLETION 


OS SIMULATION BY CMS 


TSO SERVICE ROUTINE 


On successful completion of TEOVEXIT SET Cregister 15-0), the 
RETINFO attribute contains: 


Word Meaning 


0 The symbolic tape number associated with the 
ek DDNAME (character TAP1, TAP2, TAP3, 
TAP 

The address of the FCB of the given DDNAME 
RESERVED 

RESERVED 

RESERVED 


OAD 


When in a CMS environment, a processor or a user-written program 
is executing and utilizing OS-type functions, OS is not 
controlling this action, CMS is in control. Consequently, it is 
not OS code that is in CMS, but routines to simulate, in terms 
of CMS, certain OS functions essential to the support of 0S 
language processors and their generated code. 


These functions are simulated to yield the same results as seen 
from the processing program, as specified by OS program logic 
manuals. However, they are supported only to the extent stated 
in CMS documentation and to the extent necessary to successfully 
execute 0S language processors. The user should be aware that 
restrictions to 0S functions as viewed from OS exist in CMS. 


Certain TSO Service routines are provided to allow the Program 
Products to run under CMS. The routines are the Command Scan 
and Parse Service Routines and the Terminal I/0 Service 
Routines. In addition the user must provide some initialization 
as documented in TSO TMP Service Routine initialization. The OS 
functions that CMS simulates are shown in Figure 29 on page 142. 


SUPPORT 

TSO macros that support the use of the terminal monitor program 
CTMP) service routines are contained in TSOMAC MACLIB. The macro 
functions are as described in the TSO TMP documentation with the 
exception of PUTLINE, GETLINE, PUTGET, and TCLEARQ. 


Before using the TSO service routines, the calling program 
performs the following initialization: 


1. Stores the address of the command line as the first word in 
the command processor parameter list (CPPL). The TSOGET 
macro puts the address of the CPPL in register l. 


2. Initializes CMS storage using the STRINIT macro. 
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3. Clears the ECT field that contains the address of the I[/0 
work area CECTIOWA). 


4. Issues the STACK macro to define the terminal as the primary 


source of input. 


Macro SVC No. 
XDAP 00 
WAIT 01 
POST 02 
EXIT 03 
RETURN 03 
GETMAIN 04 
FREEMAIN 05 
GETPOOL is 
FREEPOOL = 
LINK 06 
XCTL 07 
LOAD 08 
DELETE 09 
FREEMAIN 10 
GETMAIN 10 
TIME 11 
ABEND 13 
SPIE 14 
RESTORE 17 
BLDL 18 
FIND 18 
OPEN 19 
CLOSE 20 
STOW 21 
OPENJ 22 
TCLOSE 23 
DEVTYPE 24 
TRKBAL 25 
FEOV 31 
WTO/WTOR 35 
EXTRACT 40 
IDENTIFY 41 
ATTACH 42 
CHAP 44 
TTIMER 46 
STIMER 47 
DEQ 48 
SNAP 51 
ENQ 56 
FREEDBUF 57 
STAE 60 
DETACH 62 
CHKPT 63 
RDJFCB 64 
SYNAD 68 
SYNADAF = 
SYNADRLS cs 


Figure 29 (Part 1 of 2). 
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DMSSVT 
DMSSVT 
DMSSVT 
DMSSVT 
DMSSVT 


DMSSVT 
DMSSVT 
DMSSVT 


DMSSVT 
DMSSVT 
DMSSVT 


Function 


Reads or writes direct access 
volumes 

Waits for an I/0 completion 

Posts the I/0 completion 

Returns from a called phase 
Returns from a called phasa 
Conditionally acquire user storage 
Releases user-acquired storage 
Simulates as SVC 10 

Simulates as SVC 10 

Links control to another phase 
Deletes, then links control to 
another load phase 

Reads a phase into storage 
Deletes a loaded phase 
Manipulates user free storage 
Manipulates user free storage 
Gets the time of day 

Terminates processing 

Allow processing program to handle 
program interrupts 

Effective NOP 

Builds a directory list for a 
partitioned data set 

Locates a member of a partitioned 
data set 

Activates a data file 

Deactivates a data file 
Manipulates partitioned 
directories 

Activates a data file 

Temporarily deactivates a data 
file 

Obtains device-type physical 
characteristics 

Effective NOP 

Sets forced EOV error code 
Communicates with the terminal 
Effective NOP 

Adds entry to loader table 
Effective LINK 

Effective NOP 

Accesses or cancels timer 

Sets timer interval and timer exit 
routine 

Effective NOP 

Dumps specified areas of storage 
Effective NOP 

Releases a free storage buffer 
Allows processing program to 
decipher abend conditions 
Effective NOP 

Effective NOP 

Obtains information from FILEDEF 
command 

Handles data set error conditions 
Provides SYNAD analysis function 
Releases SYNADAF message and save 
areas 


Simulated OS Supervisor Calls 
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Macro SVC No. Module Function 

BSP 69 DMSSVT Backs up a record on a tape or 
disk 

DCB DMSSVT Constructs a data control block 

DCBD = DMSSVT Generates a DSECT for a data 
control block 

SAVE = DMSSVT Saves program registers 

RETURN - DMSSVT Returns from a subroutine 

GET = DMSS@S Reads system-blocked data (Q@SAM) 

PUT = DMSS@5S Writes system-blocked data (QSAM) 

READ = DMSSBS Accesses system-record data 

WRITE = DMSSBS Writes system-record data 

NOTE = DMSSCT Manages data set positioning 

POINT = DMSSCT Manages data set positioning 

CHECK = DMSSCT Verifies READ/WRITE completion 

TGET/TPUT 93 DMSSVN Reads or writes a terminal line 

TCLEARQ 94 DMSSVN Clears terminal input queue 

STAX 96 DMSSVT Creates an attention exit block 

PGRLSE 112 DMSSVT Releases storage contents 


Figure 29 (Part 2 of 2). 


CMS SIMULATION OF OS CONTROL BLOCK FUNCTIONS 


Simulated OS Supervisor Calls 


Most of the simulated supervisory 0S control blocks are 
contained in the following two CMS control blocks: 


CMSCVT 


simulates the communication vector table (CVT). 


Location 16 contains the address of the CVT control 
section. 


CMSCB 


allocated from system free storage whenever a FILEDEF 
command or an OPEN (SVC 19) 


1s issued for a data set. 


The CMS control block consists of tha CMS file Control 
block CFCB) for the data file management under CMS, and 
simulation of the job file control block (JFCB), 


input/outfut block CIOB), 
The name of the data set 
obtained from the FILEDEF argument list, 


and data extent block (DEB). 
is contained in the FCB, and is 
or from a 


predetermined file name supplied by the processing 
problem program. 


CMS also utilizes portions of the supplied data control block 
(DCB) and the data event control block (DECB). The TSO control 
blocks utilized are the command program parameters list (CPPL), 
user profile table (UPT), protected step control block (PSCB), 
and environment control table (CECT). 


OPERATING SYSTEM SIMULATION ROUTINES 


CMS provides a number of routines to simulate certain operating 
system functions used by programs such as the Assembler and the 
FORTRAN and PL/I compilers. The following paragraphs describe 
how these simulation routines work. 


XDAP-SVC 0: 
Writes and reads the source code spill file, SYSUTI, 
language compilation for PL/I Optimizer and ANS COBOL 
Compilers. 


WAIT-SVC 1: 
Causes the active task to wait until one of more event 
control blocks CECBs) have been posted. For each specified 
ECB that has been posted, one is subtracted from the number 
of events specified in the WAIT macro. If the number of 
events 15S zero by the time the last ECB is checked, control 
is returned to the user. If the number of events is not 
zero after the last ECB is checked and the number of events 
1s not greater than the number of ECBs, the active task is 


during 
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put into a wait state until enough ECBs are posted to set 

the number of events at zero. When the event count reaches 

zero the wait bits are turn off in any ECBs that have not 

been posted and control is returned to the user. If the } 
number of events specified is greater than the number of 

ECBs, the system abnormally terminates with an error 

message. All options of WAIT are supported. 


POST-SVC 2: 
Causes the specified event control block CECB) to be set to 
indicate the occurrence of an event. This event satisfies 
the requirements of a WAIT macro instruction. All options 
ee are supported. The bits in the ECB are set as 
ollows: 


Bit Setting 
0 0 


1 1 
2-7 Value of specified completion code 


EXIT-SVC 3: 
This SVC is for CMS internal use only. It is used by the 
CMS routine DMSSLN to acquire an SVC SAVEAREA on return 
from an executing program that had been given control by 
LINK (SVC 6), XTCL CSVC 7) or ATTACH (SVC 42). 


GETMAIN-SVC 4: 
Control is passed to the GETMAIN entry point in the DMSSMN 
storage resident routine. The mode is determined: VU, VC, 
EC. A call is made to GETBLK to obtain the block of 
storage. Control blocks of two fullwords precede each 
section of available storage: (1) the address of the next 
block, (2) the size of this block. The head of the pointer 
string is located at the words MAINSTRT - initial free 
block, and MAINLIST ~- address of first link in chain of 
free block pointers. All options of GETMAIN are supported 
except SP, BNDRY=, HIARCHY, LC, and LV. ) 


FREEMAIN-SVC 5: 
Releases a block of free storage. If the block is part of 
segmented storage, a control block of two fullwords is 
placed at the beginning of the released area. Adjustment 
is made to include this block in the chain of available 
areas. All options of FREEMAIN are supported except SP and 
bg 


LINK~SVC 6: 
Program transfer is controlled by the nucleus routine, 
DMSSLN. The LINK macro causes program control to be passed 
to a designated phase. If the COMPSWT bit within the byte 
OSSFLAGS is on, loading is done by calling LOADMOD to bring 
a CMS MODULE file into storage. If this flag is off, 
dynamic loading is initiated by calling LOAD. If the 
routine is already in storage, determined by scanning the 
load request chain, no LOAD or LOADMOD is done. Control is 
passed directly to the routine. CMS ignores the DCB and 
HIARCHY options; all other options of LINK are supported. 


XCTL-SVC 7: 
XCTL first deletes the current phase from storage. 
Processing then continues as for LINK-SVC 6, as previously 
described. CMS ignores The DCB and HIARCHY options; all 
other options of XCTL are supported. 


LOAD-SVC 8: 
Control is passed to DMSSLN& located in DMSSLN when a LOAD 
macro is issued. If the requested phase is not in storage, 
a LOAD or LOADMOD is issued to bring it in. Control is 
then returned to the caller. CMS ignores the DCB and 
HIARCHY options; all other options of LOAD are supported. 


DELETE-SVC 9: 
Control is passed to DMSSLNIY located in DMSSLN when a 
DELETE macro is issued. Upon entry, DELETE checks to see 
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whether the module specified was loaded using LOADMOD or 
dynamically loaded by LOAD or INCLUDE. If it was loaded by 
LOADMOD control is returned to the user. If it was 
dynamically loaded, the responsibility count is decremented 
by one and if it reaches zero, the storage is released 
using FREEMAIN, and control is returned to the user. All 
options of DELETE are supported. Code 4 is returned in 
register 15 if the phase is not found. 


GETMAIN/FREEMAIN-SVC 10: 
Control is passed to the SVC 10 entry point in DMSSMN. 
Storage management is analogous to SVC 4 and 5; 
respectively. All options of GETMAIN and FREEMAIN are 
supported. Subpool specifications are ignored. 


GETPOOL: 
Gets control via an 0S LINK macro to IECQBFGI. IECQBFGI 
allocates an area of free storage using GETMAIN, sets up a 
buffer control block in the free storage, stores the 
address of the buffer control block in the DCB, and then 
returns control to the caller. 


TIME-SVC 11: 
This routine (TIME) located in DMSSVT receives control when 
a TIME macro instruction is issued. A call is made (by SIO 
or DIAGNOSE) to the RP@ software chronological timer 
device, X'OFF*. The real time of day and date are returned 
to the calling program in a specified form. CMS supports 
the DEC, BIN, TU, and MIC parameters of the TIME macro 
instruction. However, the time value that CMS returns is 
only accurate to the nearest second and is converted to the 
proper unit. 


ABEND-SVC 13: 
This routine (CDMSSAB) receives control when either an ABEND 
macro or an unsupported 0S/360 SVC is issued. If an SVC 13 
was issued with the DUMP option and either a SYSUDUMP or 
SYSABEND ddname had been defined via a call to DMSFLD 
CFILEDEF), a SNAP CSVC 51) specifying PDATA=ALL is issued 
to dump user storage to the defined file. A check is made 
to see if there are any outstanding STAE requests. If not, 
or if an unsupported SVC was issued, DMSCWR is called to 
type a descriptive error message at the terminal. Next, 
DMSCWNT is called to wait until all terminal activity has 
ceased, and then, control is passed to the ABEND recovery 
routine. If a STAE macro was issued, a STAE work area is 
built and control is passed to the STAE exit routine. 
After the exit routine is complete, a test is made to see 
if a retry routine was specified. If so, control is passed 
to the retry routine. Otherwise, control passes to DMSABN 
unless the task that had the ABEND was a subtask. In that 
case, the resume PSW in the link block for the subtask is 
adjusted to point to an EXIT instruction (SVC 3}. The EXIT 
frees the subtask, and the attaching task is redispatched. 


SPIE-SVC 14: 
This routine (SPIE) receives control when a SPIE macro 
instruction is issued. When it gets control, SPIE inserts 
the new program interruption control area (PICA) address 
into the program interruption element (PIE). The program 
interruption element resides in the program interruption 
handler CDMSITP). It then returns the address of the old 
PICA to the calling program, sets the program mask in the 
calling program's PSW, and returns to the calling program. 
All options of SPIE are supported. 


RESTORE-SVC 17: 
RESTORE is a NOP located in DMSSVT. 


BLDL/FIND (Type D)-SVC 18: 
S to entry points in DMSSOP. If an OS disk is specified, 
DMSSVT branches and links to DMSROS. See BLDL and FIND 
under description of BPAM routines in DMSSVT. 
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STOW-SVC 21: 
See STOW under description of BRAM routines in DMSSVT. 


OPEN/OPENJ-SVC 19/22: 
OPEN simulates the data management function of opening one 
or more files. It is a nucleus routine and receives 
control from DMSITS when an executing program issues an 
OPEN macro instruction. The OPEN macro causes an SVC to 
DMSSOP. DMSSOP simulates the OPEN macro. The DISP;, 
EXTEND, and RDBACK options are ignored by CMS; all other 
options of OPEN and OPENJ are supported. You can achieve 
similar results with the EXTEND option by opening the file 
with the OUTPUT option and using the DISP MOD parameter on 
the FILEDEF command. 


CLOSE/TCLOSE-SVC 20723: 
CLOSE and TCLOSE are simulated in the nucleus routine 
DMSSOP. It receives control whenever a CLOSE or TCLOSE 
macro instruction is issued. The CLOSE macro causes an SVC 
to DMSSOP. DMSSOP simulates the CLOSE macro. CMS ignores 
the DISP option; all other options of CLOSE and TCLOSE are 
supported. 


DEVTYPE-SVC 24: 
This routine CDEVTYPE), located in DMSSVT, receives control 
when a DEVTYPE macro is issued. Upon entry, DEVTYPE moves 
Device Characteristic Information for the requested data 
set into a user specified area, and then returns control to 
the user. All options of DEVTYPE are supported, except 
RPS, which is ignored. 


TRKBAL-SVC 25: 
TRKBAL is a NOP located in DMSSVT. 


FEOV-SVC 31: 
Returns control to CMS with an error code of 4 in register 
15. 


WTO/WTOR-SVC 35: 
This routine (WTO), located in DMSSVT, receives control 
when either a WTO or a WTOR macro instruction is issued. 
For a WTO, it constructs a calling sequence to the DMSCWR 
function program to type the message at the terminal. (The 
address of the message and its length are provided in the 
parameter list that results from the expansion of the WTO 
macro instruction.) It then calls the DMSCWT function 
program to wait until all terminal I/0 activity has ceased. 
Next, it calls the DMSCWR function program to type the 
message at the terminal and returns to the calling program. 
All options of WTO and WTOR are supported except those 
concerned with multiple console support. 


For a WTOR macro instruction, this routine proceeds as 
described for WTO. However, after it has typed the message 
at the terminal it calls the DMSCRD function program to 
read the user's reply from the terminal. When the user 
replies with a message, it moves the message to the buffer 
specified in the WTOR parameter list, sets the completion 
bit in the ECB, and returns to the calling program. 


EXTRACT-SVC 40: 
This routine CEXTRACT), located in DMSSVT receives control 
when an EXTRACT macro is issued. Upon entry, EXTRACT 
clears the user provided answer area and returns control to 
the user with a return code of 4 in register 15. 


IDENTIFY-SVC 41: 
Located in DMSSVT, this routine creates a new load request 
block with the requested name and address if both are 
valid. The new entry is chained from the existing load 
request chain. The new name may be used in a LINK or 
ATTACH macro. 
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ATTACH-SVC 42: 
Located in DMSSLN, ATTACH operates like a LINK (SVC 6), 
With additional capabilities. The user is allowed to 
specify an exit address to be taken upon return from the 
attached phase; also, an ECB is posted when the attached 
phase has completed; anda STAI routine can be specified in 
case the attached phase abends. The DCB, LPMOD, DPMOD, 
HIARCHY, GSPV, GSPL, SHSPV, SHSPL, SZERO, PURGE, ASYNCH, 
and TASKLIB options are ignored; all other options of 
ATTACH are supported. Because CMS is not a multitasking 
operating system, a phase requested by the ATTACH macro 
must return to CMS. 


CHAP-SVC 44: 
CHAP is a NOP located in DMSSVT. 


TTIMER-SVC 46: 
Checks to ensure that the value in the timer Chex location 
50) was set by an STIMER macro. If it was, the value is 
converted to an unsigned 32 bit binary number specifying 26 
microsecond units and is returned in register 0. If the 
timer was not set by an STIMER macro a zero is returned in 
register 0, after setting register 0, the CANCEL option is 
checked. If it is not specified, control is returned to 
the user. If it is specified, the timer value and exit 
routine set by the STIMER macro are cancelled and control 
is returned to the user. All options of TTIMER are 
supported. 


STIMER-SVC 47: 
Checks to see if the WAIT option is specified. If so, 
control is returned to the user. If not, the specified 
timer interval is converted to 13 microsecond units and 
stored in the timer Chex location 50). If a timer 
completion exit routine is specified, it is scheduled to be 
given control after completion of the specified time 
interval. If not, no indication of the completion of the 
time interval is scheduled. After checking and handling 
any specified exit routine address, control is returned to 
the user. All options of STIMER are supported. The TASK 
option is treated as though the REAL option had been 
specified. The maximum time interval allowed is 
X*7FFFFFOO® timer units (€X'00555554' in binary, or 15 
hours, 32 minutes, and 4 seconds in decimal). If the time 
interval is greater than the maximum, it is set to the 
maximum. If running in the CMSBATCH environment, issuing 
the STIMER or TTIMER macro will affect the CMSBATCH time 
limit. Depending on the frequency, number, and duration of 
STIMER and/or TTIMER issued, the CMSBATCH time limit may 
never expire. 


DEQ-SVC 48: 
DEQ is a NOP located in DMSSVT. 


SNAP-SVC 51: 
Control is passed to SNAP in DMSSVT when a SNAP macro is 
issued. SNAP fills in a PLIST with a beginning and ending 
address and calls DMPEXEC. DMPEXEC dumps the specified 
storage along with the registers and low storage to the 
printer. Control is then returned to SNAP and SNAP checks 
to see if any more addresses are specified. It continues 
calling DMPEXEC until all the specified addresses have been 
dumped to the printer. Control is then returned to the 
user. Except for SDATA, PDATA, and DCB, all options of the 
SNAP macro are processed normally. SDATA and PDATA are 
ignored. Processing for the DCB option is as follows: The 
DCB address specified with SNAP is used to verify that the 
file associated with the DCB is open. If it is not open, 
control returns to the caller with a return code of 4. If 
the file is open, the FCB associated with the file is 
checked for a device type of DUMMY. If the device type is 
DUMMY, control returns to the caller with a return code of 
0 and storage is not dumped. 
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ENQ~-SVC 56: 
ENQ is a NOP located in DMSSVT. 


FREEDBUF-SVC 57: 
This routine CFREEDBUF ) located in DMSSVT receives control 
when a FREEDBUF macro is issued. Upon entry, FREEDBUF sets 
up the correct DSECT registers and calls the FREEDBUF 
routine in DMSSBD. This routine returns the dynamically 
obtained buffer (BDAM) specified in the DECB to the DCB 
buffer control block chain. Control is then returned to 
the DMSSVT routine which returns control to the user. All 
the options of FREEDBUF are supported. 


STAE-SVC 60: 
This routine (STAE) located in DMSSVT receives control when 
a STAE macro is issued. Upon entry, STAE creates, overlays 
or cancels a STAE control block (SCB) as requested. 
Control is then returned to the user with one of the 
following return codes in register 15: 


Code Meaning 


00 An SCB is successfully created, overlaid or 
cancelled. 
08 The user is attempting to cancel or overlay a 


nonexistent SCB. 


FORMAT OF SCB 


0€0) 
0 or pointer to next SCB 
404) |—_— 
exit address 
8(8) 
parameter list address 
12¢€C) 


DETACH-SVC 62: 
DETACH is a NOP located in DMSSVT. 


CHKPT-SVC 63: 
CHKPT is a NOP located in DMSSVT. 


RDJFCB-SVC 64: 
This routine (RDJFCB) receives control when a RDJFCB macro 
instruction is issued. When it gets control, RDJFCB 
obtains the address of the JFCB from the DCBEXLST field in 
the DCB and sets the JFCB to zero. It then reads the 
simulated JFCB located in CMSCB that was produced by 
issuing a FILEDEF into the closed area. RDJFCB calls the 
STATE function program to determine if the associated file 
exists. If it does, RDJFCB returns to the calling program. 
If the file does not exist, RDJFCB sets a switch in the DCB 
to indicate this and then returns to the calling program. 
RDJFCB is located in DMSSVT. All the options of RDJFCB are 
supported. 


e The DCB's specified in the "RDJFCB parameter list™ are 
proecees sequentially as they appear in the parameter 
ist. 


° On return to the caller, a return code of zero is 
always placed in register 15 Cif an abend occurs, 
control is not returned to the caller). 


° Abend 240 occurs if zero is specified as the address of 
the area where the JFCB will be placed. 
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e Abend 240 occurs if a "JFCB exit list entry” Centry 
type X'07') is not present in the "DCB exit list" for 
ae one of the DCB's specified in the "RDJFCB parameter 

ist." 


e If a DCB is encountered in the parameter list with zero 
specified as the "DCB exit list™ C"EXLST™) address, 
RDJFCB immediately returns with return code zero in 
register 15 -- except if all of the DCB's specified in 
the "RDJFCB parameter list™ are processed unless an 
abend occurs. 


e For a DCB that is not “open", a search is done for the 


corresponding "FILEDEF”™ and "DLBL" -~ if one is not 
found, a test is done to determine if a file exists 
with: 

filename = "FILE" 

filetype = ddname from DCB 

filemode = "Al" 


If such a file does exist, X'40' is placed in the JFCB 
at displacement X'"57' Cflag "JFCOLD” in field 
"JFCBIND2"). If such a file does not exists, X‘'CO* 
(flag "JFCNEW" will be in field "JFCBIND2". 


e For a file that is not “open,” but a "DLBL™ has been 
specified, X'08" is placed in the JFCB at displacement 
X'63' (field "JFCDSORG" byte 2) to indicate that it is 
a VSAM file. 


Note: The switch set by the RDJFCB is tested by the 
FORTRAN object-time direct-access handler (DIOCS) to 
determine whether or not a referenced disk file exists. If 
it does not, DIOCS initializes the direct access file. 


SYNAD-SVC 68: 
Located in DMSSVT, SYNAD attempts to simulate the functions 
SYNADAF and SYNADRLS. SYNADAF expansion includes an SVC 68 
and a high-order byte in register 15 denoting an access 
method. SYNAD prepares an error message line, swap save 
areas and register 13 pointers. The message buffer is 120 
bytes: bytes 1-50, 84-119 blank; bytes 51-120, 1205 
INPUT/OUTPUT ERROR nnn ON FILE: "dsname"™; where nnn is 
the CMS RDBUF/WRBUF error code. All the options of SYNAD 
are supported. 


SYNADRLS expansion includes SVC 68 and a high order byte of 
X'FF’ in register 15. The save area is returned, and the 
message buffer is returned to free storage. 


BACKSPACE-SVC 69: 
Also in DMSSVT.For a tape, a BSR command is issued to the 
tape. For a direct access data set, the CMS write and read 
pointers are decremented by one. Control is passed to 
BACKSPACE in DMSSVT when a BACKSPACE macro is issued. 
BACKSPACE decrements the read write pointer by one and 
returns control to the user. No physical tape or disk 
adjustments are made until the next READ or WRITE macro is 
issued. All the options of BACKSPACE are supported. 


TGET/TPUT-SVC 93: 
Located in DMSSVN, this routine receives control when a 
TGET or TPUT macro is issued. It is provided to support TSO 
service routines needed by program products. TGET reads a 
terminal line; TPUT writes a terminal line. The return code 
is zero if the operation was successful anda four if an 
error was encountered. 


TCLEARQ-SVC 94: 
TCLEARQ is located in DMSSVN and causes the terminal input 
queue to be cleared via a call to DESBUF. At completion a 
return is made to the user. 
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STAX-SVC 96: 
Located in DMSSVT, STAX gets and chains a CMSTAXE control 
block for each STAX SVC issued with an exit routine address 
specified. The chain is anchored by TAXEADDR in DMSNUC. If 
no exit address is specified the most recently added 
CMSTAXE is cleared from the chain. If an error occurs 
during STAX SVC processing, a return code of eight is 
placed in register 15. The only option of STAX which may be 
specified is EXIT ADDRESS. 


PGRLSE-SVC 112: 
Located in DMSSVT, PGRLSE receives control when a PGRLSE 
macro instruction is issued. The routine checks the 
validity of the beginning and end addresses of the area to 
be freed, or forces the right values (AUSRAREA to the 
beginning, or FREELOWE to the end). Then the routine 
checks the length of the area to find out if at least 1 
page (4K bytes) has to be released and issues a DIAGNOSE 
code X'10' instruction to CP. The return code will set to 
zero in register 15 if the PGRLSE operation is successful, 
or to four if only a portion of the area is released. 


GET/PUT: 
See the DMSSQ@S prolog for description. 


READ/WRITE: 
OS READ and WRITE macros branch and link to DMSSBS. DMSSBS 
branches and links to DMSSEB and, if the disks is an OS 
disk, DMSSEB branches and link to DMSROS. See DMSSBS for 
description. 


NOTE/POINT/FIND (Type C): 
OS NOTE, POINT, and FIND Ctype c) macros branch and link to 
entry points in DMSSCT. If the disk is an OS disk, DMSSCT 
branches and links to DMSROS. See DMSSCT for descriptions. 


CHECK: 
See the DMSSCT prolog for description. 


Notes on using the OS simulation routines: 


e CMS files are physically blocked in 800-byte blocks, and 
logically blocked according to a logical record length. If 
the filemode of the file is not 4, the logical record length 
is equal to the DCBLRECL and the file must always be 
referenced with the same DCBLRECL, whether or not the file 
is blocked. If the filemode of the file is 4, the logical 
record length is equal to the DCBBLKSI and the file must 
always be referenced with the same DCBBLKSI. 


° When writing CMS files with a filemode number other than 
four, the OS simulation routines deblock the output and 
write it on a disk in unblocked records. The simulation 
routines delete each 4-byte block descriptor word (BDW) and 
each 4-byte record descriptor word (RDW) of variable length 
records. This makes the OS-created files compatible with 
CMS-created files and CMS utilities. When CMS reads a CMS 
file with a filemode number other than four, CMS blocks the 
record input as specifies and restores the BDW and RDW 
control words of variable length records. 


If the CMS filemode number is four, CMS does not unblock or 
delete BDWs or RDWs on output. CMS assumes on input that 
the file is blocked as specified and that variable length 
records contain block descriptor words and record descriptor 
words. 


e To set the READ/WRITE pointers for a file at the end of the 
file, a FILEDEF command must be issued for the file 
specifying the MOD option. 


° A file is erased and a new one created if the file is opened 
and all the following conditions exist: 
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= The OUTPUT or OUTIN option of OPEN is specified. 
aad The TYPE option of OPEN is not J. 


sd The dataset organization option of the DCB is not direct 
access or partitioned. 


= A FILEDEF command has not been issued for data set 
specifying the MOD option. 


e The results are unpredictable if two DCBs read and write to 
the same data set at the same time. 


COMMAND FLOW OF COMMANDS INVOLVING OS ACCESS 


ACCESS COMMAND FLOW: The module DMSACC gets control first when 
you invoke the ACCESS command. DMSACC verifies parameter list 
validity and sets the necessary internal flags for later use. 

If the disk you access specifies a target mode of another disk 
currently accessed, DMSACC calls DMSALU to clear all pertinent 
information in the old active disk table. DMSACC then calls 
DMSACF to bring in the user file directory of the disk. As Soon 
as DMSACF gets control, DMSACF calls DMSACM to read in the 
master file directory of the disk. Once DMSACM reads the label 
of the disk, and determines that it is an OS disk, DMSACM calls 
DMSROS CROSACC) to complete the access of the OS disk. Upon 
returning from DMSROS, DMSACM returns immediately to DMSACF, 
bypassing the master file directory logic for CMS disks. DMSACF 
then checks to determine if the accessed disk is an OS disk. If 
it is an OS disk, DMSACF returns immediately to DMSACC, 
bypassing all the user file directory logic for OS disks. 

DMSACC checks to determine if the accessed disk is an OS disk; 
if it is, another check determines if the accessed disk replaces 
another disk to issue an information message to that effect. 
Another check determines if you specified any options or fileid 
and, if you did, a warning message appears on the terminal. 
Control now returns to the calling routine. 


FILEDEF COMMAND FLOW: DMSFLD gets control first when you issue 
a CMS FILEDEF command. DMSFLD adds, changes, or deletes a 
FILEDEF control block (CMSCB) and returns control to the calling 
routine. 


LISTDS COMMAND FLOW: The module DMSLDS gets control first when 
you invoke the LISTDS command. DMSLDS verifies parameter List 
validity and calls module DMSLAD to get the active disk table 
associated with the specified mode. DMSLDS reads all format 1 
DSCB and if you specified the PDS option and the data set is 
partitioned, DMSLDS calls DMSROS CROSFIND) to get the members of 
the data set. After displaying the DSCB Cor DSCB) on you 
console, DMSLDS returns to the calling routine. 


OSRUN COMMAND FLOW: The module DMSOSR gets control first when 
you invoke the OSRUN command. DMSOSR checks the command syntax. 
The PARM=parameter, if specified, is set up according to OS 
convention and a LINK (SVC 6) is issued for the member specified 
in the OSRUN command. DMSITS (the SVC FLIH) passes control to 
DMSSVT which in turn goes to DMSSLN for processing of the LINK 
SVC. DMSSLN passes control to DMSLOS. DMSLOS loads, relocates, 
and executes the member specified. When the member completes 
execution and returns control to DMSLOS, DMSLOS returns to 
DMSSLN for some cleanup; DMSSLN goes through the normal SVC 
return to DMSOSR. DMSOSR goes through its termination and 
returns to CMS. 


MOVEFILE COMMAND FLOW: The module DMSMVE gets control first 
when you issue a CMS MOVEFILE command. DMSMVE calls DMSFLD to 
get an input and output CMSCB and, if the input DMSCB is for a 
disk file, DMSMVE calls DMSSTT to verify the existence of the 
input file and get default DCB parameters in absence of CMSCB 
DCB parameters. DMSMVE uses OS OPEN, FIND, GET, PUT, and CLOSE 
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macros to move data from the input file to the output file. 
ani moving the specified data, control returns to the calling 
routine. 


LKED COMMAND FLOW: The module DMSLKD gets control first when J 
you invoke a CMS LKED command. DMSLKD generates the necessary 
FILEDEFs for execution of the OS linkage editor and calls the 
linkage editor CHEWLFROU). When the link-edit is complete, 
pene receives control to do some clean up prior to returning 
o " 


QUERY COMMAND FLOW: The module DMSQRY gets control first when 
you invoke the QUERY command. DMS@QRY verifies parameter list 
validity and passes control to DMSQ@RS that calls DMSLAD to get 
the active disk table associated with the specified mode. 
DMSQRY displays all the information that you requested on your 
console. When DMS@QRY finishes, control returns to the calling 
routine. 


RELEASE COMMAND FLOW: The module DMSARE gets control first when 
you invoke the RELEASE command. DMSARE verifies parameter list 
validity and checks to determine if the disk you want to release 
is accessed. If the disk you want to release is currently 
active, DMSARE calls DMSALU to clear all pertinent information 
associated with the active disk. DMSALU first checks the active 
disk table for any existing CMS tables kept in free storage. If 
the disk you want to release is an OS disk, DMSALU does not find 
any tables associated with a CMS disk. If the disk is an OS 
disk, DMSALU releases the OS FST blocks Cif any) and clears any 
OS FST pointers in the OS file control blocks. DMSALU then 
clears the active disk table and returns to DMSARE. DMSARE then 
clears the device table address for the specified disk and 
returns to the calling routine. 


STATE COMMAND FLOW: The module DMSSTT gets control first when 
you invoke the STATE command. DMSSTT verifies the parameter 
list validity and calls module DMSLAD to get the active disk 
table associated with the specified mode. Upon return from 
DMSLAD, DMSSTT calls DMSLFS to find the file status table (FST) 
associated with the file you specified. Once DMSLFS finds the 
associated FST, it checks to determine if the file resides on an 
OS disk. If it does, DMSLFS calls DMSROS CROSSTT) to read the 
extents of the data set. Upon return from DMSROS, DMSLFS 
returns to DMSSTT. DMSSTT then copies the FST (Cor OS FST) to 
the FST copy in statefst and returns to the calling routine. 


OS ACCESS METHOD MODULES--LOGIC DESCRIPTION 


DMSACC MODULE: Once DMSACC determines that the disk you want to 
access is an OS disk, it bypasses the routines that perform 
LOGIN UFD and LOGIN ERASE. 


If the disk you want to access replaces an OS disk, message 
DMSACC7241I appears at your terminal. 


If you specified any options or fileid in the ACCESS command to 
an OS disk, a Warning message, DMSACC230W, appears to notify you 
that such options or fileid were ignored. DMSACC returns to the 
calling routine with a Warning code of 4. 


DMSACF MODULE: DMSACF verifies that the disk you want to access 
is an OS disk and, if it is, exits immediately. 


DMSACM MODULE: DMSACM saves the disk label and VTOC address in 
the ADT block if the disk is an OS disk. DMSACM checks to 

determine if a previous access to an OS disk loaded DMSROS. If 
not, DMSACM calls DMSSTT to verify that DMSROS text exists. 

Upon successful return from STATE, DMSACM loads DMSROS text into 
the high storage area with the same protect key and calls the OS 
access routine CROSACC) of DMSROS to read the format 4 DSCB of ; 


the disk. Upon successful return from DMSROS, control returns 
to the calling routine. Any other errors are treated as general 
logon errors. 
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DMSALU MODULE: If the disk is an 0S disk, DMSFRET returns the 
0S FST blocks Cif any) to free storage. DMSALU clears the OS 
FST pointer in all active 05 file control blocks, decrements the 
DMSROS usage count and, if the usage count is zero, clears the 
address of DMSROS in the nucleus area. DMSALU also calls 
DMSFRET to returns to free storage the area which DMSROS 
occupies. 


DMSARE MODULE: DMSARE ensures that the disk you want to release 
is an 0S disk. DMSARE calls DMSALU to release all OS FST blocks 
and, if necessary, to free the area DMSROS occupies. Upon 
return from DMSALU, DMSARE clears the common CMS and OS active 
disk table. 


DMSFLD MODULE: 


e DSN -- If you specify the parameter DSN as a question mark 
(?)}, FILEDEF displays the message DMSFLD220R to request you 
to type in an OS data set name with the format Q1.Q2.QN. 

Ql, Q@2, and QN are the qualifiers of an OS data set name. 

If you specify the parameter DSN as Q1.Q92.QN, FILEDEF 
assumes that Q1, Q2, and QN are the qualifiers of an 05 data 
set name, and stores the qualifiers with the format @1.Q2.QN 
in a free storage block and chains the block to the FCB. 


© CONCAT -- If you specify the CONCAT option, FILEDEF assumes 
that the specified FILEDEF is unique unless a filedef is 
outstanding with a matching ddname, filename, and filetype. 
This allows you to specify more than one FILEDEF for a 
particular ddname. The CONCAT option also sets the FCBCATML 
bit in the FCB to allow the OS simulation routine to know 
the FCB is for a concatenated MACLIB. 


e MEMBER ~-- If you specify the member option, filedef stores 
the member name in FCBMEMBR in the FCB to indicate that the 
0S simulation routine should set the read/write pointer to 
point to the specified BPAM file member when OPEN occurs. 


DMSLDS MODULE: DMSLDS saves the return register, sets itself 
with the nucleus protection key, clears the dsname key, and 
initializes its internal flag. 


DMSLDS verifies parameter list validity. The data set name must 
not exceed $4 characters, and the disk mode (the last parameter 
before the options) must be valid. DMSLDS joins the qualifiers 
with dots ¢€.) to form valid data set names. If you specify the 
data set name as a question mark (7), DMSLDS prompts you to 
enter the dsname in exactly the same form as the dsname which 
appears on the disk. 


DMSLDS calls DMSLAD to find the active disk table block. If you 
specify filemode as an asterisk (*%), DMSLAD searches for all ADT 
blocks. If you specify the filemode as alphabetic, DMSLAD finds 
only the ADT block for the specified filemode. 


If you specify the dsname (which is optional), DMSLDS sets 
the channel programs to read by key. If you did not specify a 
dsname, DMSLDS searches the whole VTOC for format 1 DSCBS and 
displays all the requested information contained in the DSCB on 
your console. If you specify the format option, the RECFM, 
LRECL, BLKSI, DSORG, DATE, LABEL, FMODE, and data set name 
appear on you console; otherwise, only the FMODE and data set 
name appear. 


If you specify the PDS option, DMSLDS calls the ‘find’ routine 
Crosfind) in DMSROS to read the member directory and pass back, 
one at a time, in the fcbmembr field of CMSCB the name of each 
member of the data set. This occurs if the data set is 
partitioned. 


After processing finishes, DMSLDS resets the nucleus key to the 


same value as the user key, puts the return code in register 15, 
and returns to the calling routine. 
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DMSLFS MODULE: DMSLFS verifies that the FST being searched for 

has an OS disk associated with it. DMSLFS calls the DMSROS 

state routine CROSSTT) to verify that the data set exists and ' 
CMS supports the data set attributes. Upon return from DMSROS, ) 
a return code of 8& indicates that the data set was not found, 

and DMSLDS starts the search again using the next disk in 

sequence. Any other errors, such as a return code 80, cause 

DMSLFS to exit immediately. A return code of 0 from DMSROS 

indicates that the data set is on the specified disk. From this 

point on, execution occurs common to both CMS and OS disks. 


DMNSMVE MODULE: If you specify the PDS option and the input is 
from a disk, DMSMVE sets the FCBMVPDS bit and issues an OS FIND 
macro before opening an output DCB to position the input file at 
the next member. DMSMVE then stores the input member name in 
the output CMSCB for use as the output filename. After reaching 
end-of-file on a member, the message DMSMVE225I appears, DMSMVE 
closes the output DCB, and passes control to find the next 
member. After moving all the members to separate CMS files, 
movefile displays message DMSMVE226I, closes the input and 
output DCBS, and returns control to the calling routine. 


DMSROS MODULE: 


° ROSACC Routine -~- ROSACC gets control from DMSACM after 
DMSACM determines that the label of the disk belongs to an 
OS disk. The ROSACC routine reads the format 4 DSCB of the 
disk to further verify the validity of the 0S disk. ROSACC 
updates the ADT to contain the address of the high extent of 
the VTOC Cif the disk is a DOS disk) or the address of the 
last active format 1 DSCB Cif the disk is an OS disk), and 
the number of cylinders in the disk. If the disk is a DOS 
disk, ROSACC sets a flag in the ADT. Information messages 
appear to notify you that the disk was accessed in read-only 
mode. If the disk is already accessed as another disk, 
another information message appears to that effect. Finally 
ROSACC zeroes out the ADTFLG1 flag in the ADT, sets the 
ADRFLG2 flag to reflect that an OS disk was accessed, and 
returns control to the calling routine. 


® ROSSTT Routine -- Verifies the existence of an OS data set 
and verifies the support of the data set attributes. 


Note: Within the ROSSTT description, any reference to FCB 
or CMSCB implies a DOSCB if DOS is active. 


ROSSTT gets control from DMSSTT after DMSSTT determines that 
the STATE operation 1s to an OS disk. The ROSSTT routine 
searches for the correct FCB which a previous FILEDEF 
associated with the data set. If the DOS environment is 
active, ROSSTT locates the correct DOSCB that defines a data 
set described by a previous DLBL. If ROSSTT finds an active 
FST, control passes to ROSSTRET; otherwise, ROSSTT acquires 
the dsname block, places its address in the FCB, and moves 
the dsname in the FCB to the acquired block. ROSSTT 
acquires an FST block, chains it to the FST chain, and fills 
all general fields (dsname, disk address, and disk mode). 
ROSSTT now reads the format 1 DSCB for the data set and 
checks for unsupported options (CBDAM, ISAM, VSAM, and read 
protect). 


Errors pass control back to the calling routine with an 
error code. ROSSTT groups together all the extents of the 
data set (by reading the format 3 DSCB if necessary) and 
checks them for validity. ROSSTT bypasses any user labels 
that may exist and displays a message to that effect. Next, 
ROSSTT moves the DSCB1 BLKSIZE, LRECL, and RECFM parameters 
to the OS FST and passes control to ROSSTRET. 


° ROSSTRET Routine -- If the disk is not a DOS disk, ROSSTRET 
passes control back to the caller. If the specified disk is 
a DOS disk, ROSSTRET fills in the OS FST BLKSIZE, LRECL, and 
RECFM fields that were not specified in the DSCBl. If the 
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CMSCB fields are zero, ROSSTRET defaults them to 
BLKSIZE=32760, LRECL=32670, and RECFM=U. Control then 
returns to the calling routine. 


ROSRPS Routine -- ROSRPS reads the next record of an OS data 
set. Upon entry to the ROSRPS entry point, ROSRPS calls 
CHKXTNT and, if the current CCHHR is zero, SETXTNT to ensure 
the CCHHR and extent boundaries are correctly set. ROSRPS 
then calls DISKIO and, if necessary, CHKSENSE and GETALT to 
read the next record. If no errors exist or an 
unrecoverable error occurred, control returns to the user 
with either a zero (I/O OK) or an 80 (I/O error) in register 
15. If an unrecoverable error occurs, ROSRPS updates the 
CCWS and buffer pointers as necessary and recalls CHKXTNT 
and DISKIO to read the next record. 


ROSFIND Routine -~- ROSFIND sets the CCHHR to point toa 
member specified in FCBMEMBR or, if the FCBMVPDS bit is on, 
sets the CCHHR to point to the next member higher than 
FCBMEMBR and sets a new member name in FCBMEMBR. 


Upon entry at the ROSFND entry point, ROSFND sets up a CCW 
to search for a higher member name if the FCBMVPDS bit is 
on, or an equal member name if the FCBMVPDS bit is off. It 
then calls SETXTNT, DISKIO and, if needed, CHKSENSE and 
GETALT to read in the directory block that contains the 
member name requested. After reading the block, it is 
searched for the requested member name. If the member name 
is not found, an error code 4 returns to the calling 
routine. If an I/0 error occurs while trying to read the 
PDS block, an error code 8 returns to the calling routine. 
If the member name is found, TTRCNVRT is called to convert 
the relative track address to a CCHH and pass the address of 
the member entry to the calling routine. 


ROSNTPTB Routine -- ROSNTPTB gets the current TTR, sets the 
current CCHHR to the value of the TTR, and backspaces to the 
previous record. 


Upon entry at the ROSNTPTB entry point, ROSNTPTB checks to 
determine if a NOTE, POINT, or BSP operation was requested. 


If register 90 is zero, NOTE is assumed. The note routine 
calls CHRCNVRT to convert the CCHH to a relative track and 
returns control to the calling routine with the TTR in 
register 0. 


If register 0 is positive upon entry into DMSROS, POINT is 
assumed and ROSNTPTB loads a TTR from the address in 
register 0 and calls TTRCNVRT and SETXTNT to convert the TTR 
to a CCHHR. Then control returns to the calling routine. 


If register 0 is negative upon entry into DMSROS, BSP 
CBACKSPACE) is assumed. The backspace code checks to 
determine if the current position is the beginning of a 
track. If not, the backspace code decrements the record 
number by one and control then returns to the calling 
routine. If the current position is the beginning of a 
track, the backspace code calls CHRCNVRT to get the current 
CCHH. The backspace code then calls rdcent to get the 
current record number of the last record on the new track, 
calls setxtnt to set the new extent boundaries, and returns 
control to the calling routine. 


DMSSCT MODULE: 


NOTE Routine -- Upon entry to note, DMSSCT checks to 
determine if the DCB refers to an OS disk. If it does, 
DMSSCT calls DMSROS CROSNTPTB) to get the current TTR. 
Control then returns to the user. 
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e POINT Routine ~~ Upon entry to point, DMSSCT checks to 
determine if the DCB refers to an OS disk. If it does, 
DMSSCT calls DMSROS CROSNTPTB) to reset the current TTR, ) 
calls CKCONCAT and returns control to the calling routine. 


° CKCONCAT Routine -- Upon entry to CKCONCAT, DMSSCT checks to 
determine if the FCB MACLIB CONCAT bit is on. If it is on; 
DCBRELADt+3 sets the correct OS FST pointer in the FCB and 
returns control to the calling routine. If the FCB MACLIB 
CONCAT bit is off, control returns to the calling routine. 


° FIND (type_C) Routine -- If the DCB refers to an OS disk, 
DMSSCT calls DMSROS CROSNTPTB) to update the TTR and control 
returns to the calling routine. 


DMSSEB MODULE: 


° EOBROUTN Routine ~~ If the FCB OS bit is on, control passes 
to OSREAD. Otherwise, if no special I/O routine is 
specified in FCBPROC, control passes to EOB2 in DMSSEB. 


e OSREAD Routine ~~ DMSSEB calls DMSROS to perform a read or 
write and then control passes to EOBRETRN which, in turn, 
passes control back to DMSSBS. DMSSBS passes control back 
to the routine calling the read or write macro operation. 


DMSSOP MODULE: If the MACLIB CONCAT option is on in the CMSCB, 
OPEN checks the MACLIB names in the global list and fills in the 
addresses of OS FSTS for any MACLIBS on OS disks. The CMSCB of 
the ae MACLIB in the global list merges and initializes 
CMSCBS. 


If the CMSCB refers to a data set on an OS disk, DMSSOP checks 

to ensure that the data set is accessible and the DCB does not 

specify output, BDAM, or a key length. If any errors occur, 

error message DMSSOPO36E appears and DMSSOP does not open the 

DCB. DMSSOP fills them in from the OS FST for the data set. 


If the CMSCB fcbmembr field contains a member name (filled in by 
FILEDEF with the member option), DMSSOP issues an OS FIND macro 
to position the file pointer to the correct member. If an error 
occurs on the call to the FIND macro, error message DMSSOPO36E 
appears and DMSSOP does not open the DCB. 


DMSSVT MODULE: 


e BSP Cbackspace) Routine -- Upon entry, backspace checks for 
the FCB OS bit. If it is on, the BSP routine calls DMSROS 
CROSNTPTB) to backspace the TTR and control returns to the 
calling routine. 


° FIND (type_D) Routine -- Upon entry to find, the find 
routine checks the FCB OS bit. If it is on, the FIND 
routine takes the OS FST address from the CMSCB or, if the 
CONCAT bit is on, from the global MACLIB list. The FIND 
routine then calls DMSROS CROSFIND) to find the member name 
and TTR. DMSROS searches for a matching member name or, if 
the FCBMVPDS option is specified, a higher member name. If 
the DMSROS return code is 0 or 8, or if the FCBCATML bit is 
not on, control returns to the calling routine with the 
return code from DMSROS. If the return code is 4 and the 
FCBCATML bit is on, DMSSVT checks to determine if all the 
global MACLIBS were searched. If they were, control returns 
to the calling routine with the DMSROS return code. If they 
were not, DMSSVT issues the FIND on the next MACLIB in the 
global list. 


° BLDL Routine--BLDL list = FF LL NAME TTR KZC DATA 


If the DCB refers to an OS disk, the BLDL routine fills in 
the TTR, C-byte and data field from the OS data set. 
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DMSQRS MODULE: 


e SEARCH Routine -- The search routine ensures that any OS 
disk currently active is included in the search order of all 
disks currently accessible. 


e DISK Routine -- The disk routine displays the status of any 
or all OS disks using the following form: 


"MODECCUU): CNO. CYLS.), TYPE R/O - OS.° 


DMSSTT MODULE: DMSSTT verifies that the disk being searched is 
an OS disk. DMSSTT calls DMSLFS to get the FST associated with 
the data set. Upon return from DMSLFS, DMSSTT checks the return 
code to ensure that CMS supports the data set attributes. A 
return code of 8&1 or 8&2 indicates that CMS does not support the 
data set and message DMSSTT229E occurs to that effect. DMSSTT 
then clears the FST copy with binary zeros, and moves the 
filename, filetype, filemode, BLKSIZE, LRECL, RECFM, and flag 
byte to the FST copy. From this point on, common code execution 
occurs for both CMS and OS disks. 


Routines Common to All of DMSROS 


e CHRCNVRT Routine -- The CHRNCVRT routine converts a CCHH 
address to a relative track address. 


e CHKSENSE Routine ~- CHKSENSE checks sense bits to determine 
the recoverability of a unit check error if one occurs. 


° CHKXTNT Routine -- CHKXTNT checks to determine if the end of 
split cylinder or the end of extent occurred, and, if so, 
updates to the next split cylinder or extent. 


e DISKIO Routine -- DISKIO starts I/O operation on a CCW 
string via a DIAGNOSE X'20". 


e GETALT Routine -- GETALT switches reading from alternate 
track to prime track, and from prime track to alternate 
ie: se Sie track. 


e RDCNT Routine -- RDCNT reads count fields on the track to 
determine the last record number on the track. 


° SETXTNT Routine ~~ SETXTNT sets OSFSTEND to the value of the 
end of the extent and, if a new extent is specified, sets 
CCHHR to the value of the start of the extent. 


SIMULATING A VSE ENVIRONMENT UNDER CMS 


CMS/DOS is a functional enhancement to CMS that provides VSE 
installations with the interactive capabilities of a VM/SP 
virtual machine. CMS/DOS operates as the background VSE 
partition; other VSE partitions are unnecessary, since the 
CMS/DOS virtual machine is a one-user machine. 


CMS/DOS provides read access to real VSE data sets, but not 
write or update access. Real VSE private libraries, system 
relocatable libraries, source statement libraries, and 
core-image libraries can be read. This read capability is 
supported to the extent required to support the CMS/DOS linkage 
editor, the DOS/PLI, DOS/VS COBOL, and the DOS/VS RPG II 
compilers, the FETCH routine, and the RSERV, SSERV, and ESERV 
commands. No read or write capability exists for the VSE 
procedure library, except for copying procedures from the 
Procedure library (via the PSERV command) or displaying the 
procedure library (via the DSERV command). 


CMS/DOS does not support the standard label area. 
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INITIALIZING VSE AND PROCESSING VSE SYSTEM CONTROL COMMANDS 


Initialization of the CMS/DOS operating environment requires the } 
setting of flags and the creation of certain data areas in 

storage. Once inittalized, these flags and data areas may then 

be changed by routtnes invoked by the system control commands. 


DMSSET -- Initializing the CMS/DOS Operating Environment 
DMSSET initializes the CMS/DOS operating environment as follows: 


e eee that the mode, if specified, is for a DOS formatted 
disk. 


e Stores appropriate data in the SYSRES LUB and PUB. 


e Locates and loads the CMS/DOS discontiguous shared segment. 
Saves Cin NUCON) the addresses of the two major CMS/DOS data 
blocks, SYSCOM and BGCOM, and the address of the CMS/DOS 
discontiguous shared segment CCMSDOS). 


e Locates and loads the CMSBAM shared segment if available. 
This segment contains the following: 


= Simulated VSE OPEN/CLOSE and logic module routines for 
the VSE sequential access method 


= BTFSL support for the DOS PL/I and DOS/VS5 COBOL 
compilers 


_ LBROPEN, LBRFIND, and LBRGET macro simulation as 
required by the VSE ESERV program 


oa VSE lookaside function support as required by VSE/VSAM 


e Obtains free storage and initializes the LOCK/UNLOCK ) 
resource control table. 


° Sets the DOSMODE, DOSSVC and CMSBAM bits in DOSFLAGS in 
NUCON. 


e Assigns (via ASSGN) the SYSLOG logical unit as the CMS 
virtual console. 


The CMS/DOS operating environment is entered when the CMS SET 
DOS ON command is issued, invoking the module DMSSET. 


Data Areas Prepared for Processing During CMS/DOS Initialization 


Several data areas are prepared for processing during 
initializatton. The main CMS data area, NUCON, is modified to 
contain the addresses of two VSE data areas, SYSCOM and BGCOM. 
NUCON also contains the address of the Task Control Block CTCB). 


The SYSCOM DSECT is the VSE system communications region. It 
consists mainly of address constants, including the addresses of 
the boundary box, the PUB ownership table, and the FETCH table. 
It also includes such information as the number of partitions 
(always one for CMS/DOS) and the length of the PUB table. 


The BGCOM DSECT is the partition communication region. It 
includes such information as the date, the location of the end 
of supervisor storage, the end address of the last phase loaded, 
the end address of the longest phase loaded, bytes used to set 
the language translator and supervisor options, and the 
addresses of many other VSE data areas such as the LUB, PUB, 
NICL, FICL, PIB, and PIB2TAB. 


The TCB contains the addresses of the PC and AB exit routines. 
The TCB also contains the addresses of the related PC and AB 
exit save areas. 
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The LUB and PUB tables are also made available during 
initialization. The LUB is the logical unit block table. It 
acts as an interface between the user's program and the CMS/DOS 
physical units. It contains an entry for each symbolic device 
available in the system. 


Each of the symbolic names in the LUB is mapped into an element 
in the PUB, the physical unit block table. The PUB table 
contains an entry for each channel and device address for all 
devices physically available to the system and also contains 
such information as device type code, CMS disk mode, tape mode 
setting, and 7-track indicator. 


Three bits are set in DOSFLAGS in NUCON: DOSMODE, DOSSVC, and 
CMSBAM. DOSMODE specifies that this virtual machine is running 
in the CMS/DOS operating environment. DOSSVC indicates whether 
OS or VSE SVCs are operative in the operating environment. 
CMSBAM indicates that various VSE functions are supported and 
available. If DOSSVC is set, VSE SVCs are used. Otherwise, OS 
SVCs are operative. 


SETTING OR RESETTING SYSTEM ENVIRONMENT OPTIONS 


Once the CMS/DOS environment is initialized, the flags and 
control blocks set during initialization can be modified and 
manipulated to perform the functions specified by commands 
entered at the console. This section describes the modules that 
set and reset the system environment options. That is, they set 
those options that control compiler execution and that control 
the configuration of logical and physical units in the system. 


DMSOPT -=- Setting and Resetting Compiler Options 


DMSASN =~ Associate 


The CMS/D0OS OPTION command invokes module DMSOPT, which sets 
either the default options for the compiler or the options 
specified on the command line. The nonstandard language 
translator options switch and the job duration indicator byte 
are altered. Options are set using two control words located in 
the partition communication region CBGCOM). Bits in bytes JCSW3 
or JCSW4 are set, depending on the options specified. 


System or Programmer Logical Units With Physical Units 


Module DMSASN is invoked when the ASSGN command is entered. 
DMSASN first scans the command line to ensure that the logical 
unit being assigned is valid for the physical unit specified 
(for example, SYSLOG must be assigned to either the virtual 
console or the virtual printer). Once the command line is 
checked, PUB and LUB entries are modified to reflect the 
specified assignment. 


A check is made to ensure that the logical units SYSRDR or 
SYSIPT are not being assigned to a DOS formatted FB-51l2 DASD. 
This 18S not supported in the CMS/DOS environment because SVC 103 
CSYSFIL support) is not available. 


For the PUB entry, the device type is determined (via DIAG 24) 
and the device type code is placed in the PUB. Other 
modifications are made to the PUB depending on the specified 
ae rent: The LUB entry is then mapped to its corresponding 


DMSDAS -- Dynamically Associated Programmer Logical Units with Physical Units 


The function of DMSDAS is to assign a disk device with address 
X'cuu' to a programmer logical unit CSYS000 - SYS241). 


The dynamic assign function supports assigning a DASD unit 
either permanently or temporarily, changing a DASD unit 
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temporary assign to permanent, or unassigning a DASD. Temporary 
assigns are cleared either at end-of-job or when the program is 
canceled. 


DMSDAS first searches the Active Disk Table (ADT) chain to 
ensure that the X'cuu’ supplied is accessed. If the X'cuu' 
exists, DMSDAS ensures the device is a DASD unit. The 
programmer LUB table is then searched backwards to find the 
first available entry. <A CMS PLIST is built using the found LUB 
entry to call DMSASN to actually do the assign. 


DMSDAS updates the appropriate LUB entry directly when 
performing the unassign and change functions. 


DMSLLU -- List the Assignments of CMS/DOS Physical Units to Logical Units 


DMSDLB -- Associate 


The function of DMSLLU is to request a list of the physical 
units assigned to logical units. It performs this function by 
referencing information located in the CMS/DOS data blocks, 
specifically SYSCOM, 

LUB, and PUB. Another data block, the next in class (NICL) 
table is also referenced. 


The information on the command line is scanned and the 
appropriate items are displayed at the user's console. If an 
option CEXEC or APPEND) is specified, an EXEC file is created 
CS$LISTIO EXEC Al) to contain the output. If EXEC is specified, 
any existing $LISTIO EXEC Al file is erased and a new one is 
created. If APPEND is specified, the new file is appended to 
the existing file. 


a DTF Table Filename With a Logical Unit 


DMSDLB is invoked when the CMS/DOS DLBL command is entered. 
DMSDLB associates a DTF (Define The File) table filename with a 
logical unit. This function is performed by creating a control 
block called a DOSCB, which contains information defining a VSE 
file used during job execution. DLBL is valid only for 
sequential or VSAM disk devices. 


This information parallels the label information written on a 
real VSE SYSRES unit under VSE. The DOSCB contains such 
information as the name, type, and mode of the referenced 
dataset, its device type code, its logical unit specification, 
and its dataset type (SAM or VSAM). 


A DOSCB is created for each file specified by the user during a 
terminal session. The DOSCBs are chained to each other and are 
anchored in NUCON at the field DOSFIRST. The chain remains 
intact for the entire session, unless an abend occurs or the 
user specifically clears an entry in the the DOSCB chain. A 
given DOSCB is accessed when an OPEN macro is issued from an 
executing user program. 


The overall logic flow for DMSDLB is as follows: 


° Scans the command line to ensure that any options entered 
are valid (that is, anything to the right of the open 
parenthesis). 


e Processes the first operand (ddname or *). When ddname is 
specified, loop through the DOSCB chain to find a matching 
ddname. If none is found, DMSDLB calls DMSFRE to get storage 
to create a new DOSCB for this file. The old copy of the 
DOSCB is then saved so that, in case of errors during 
processing, it can be retrieved intact. The new copy of the 
DOSCB contains updates, and DOSCB replaces the old copy if 
there are no errors. 
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° The mode specification is checked to ensure that it is a 
valid mode letter; if the file is a CMS file, the mode 
letter must specify a CMS disk. If DSN has been specified, 
the mode letter must be for a non-CMS disk. 


° Process each option on the command line appropriately. 


° If EXTENT or MULT is specified, a separate block of free 
storage is obtained to contain information about the extent; 
for axample, a block is obtained to contain the VSE data set 
name. 


e Check for errors. If there are errors, any blocks created 
during processing are purged and an error message is issued. 
If there are no errors, restore the old block, which has 
been modified to reflect current processing, and return 
control to DMSITS. 


PROCESS CMS/DOS OPEN AND CLOSE FUNCTIONS 


The CMS/DOS OPEN routines are invoked in response to VSE OPEN 
macros. They operate on DTF (define the file) tables and ACB 
Caccess method control block) tables created when the DIFxx and 
ACB macros are issued from an executing user program. These 
tables contain information such as the logical unit 
specification for the file, the DIF type of the file, the device 
code for the file, and so forth. The information in the tables 
varies depending upon the type of DTF specified (that is, the 
table generated by a unit record DTF macro is slightly different 
from the table generated by a DTF disk macro). 


Five routines are invoked to perform OPEN functions, DMSOPL, 
DMSOR1, DMSOR2, DMSOR3, and DMSBOP. DMSCLS performs the CLOSE 
function. 


OPEN/CLOSE processing in the CMS/DOS environment depends upon 
the DTF type: 


° For DTFCP (disk), DTFDI (disk), and DTFSD DTF types, actual 
OPEN/CLOSE processing is performed by the simulated VSE SAM 
routines in the CMSBAM DCSS. 


e For all other supported DIF types, OPEN/CLOSE processing is 
performed totally within the CMS/DOS modules mentioned 
above. 


Opening Files Associated With DTF Tables 


Depending on the type of OPEN macro issued from a user program, 
one of five CMS/DOS OPEN routines could be invoked. OPENR 
macros give control to DMSORI1, and depending on the DTF type 
specified, DMSOR2 or DMSOR3 may be invoked. These three 
routines CDMSOR1L, DMSOR2, and DMSOR3) request the relocation of 
a specified file. DMSOPL is invoked by thea VSE compilers when 
they need access to a source statement library. These routines 
are mainly interface routines to DMSBOP, which performs the main 
function of opening the specified file. Each of the routines 
calls DMSBOP. 


DMSBOP is the CMS/DOS routine that simulates the VSE OPEN 
function for nondisk DTFs. The basic function of DMSBOP for 
nondisk DTFs is the initialization of DTF tables (that is, 
setting fields in specified DTFs for use by the VSE LIOCS 
routines). For disk DTFs, DMSBOP services as an interface 
routine and passes control the the CMSBAM DCSS. 


When a VSE problem program is compiling, a list of DTFs and ACBs 

is built. At execution time, this list is passed to DMSBOP. 

The logic flow of DMSBOP is as follows: 

l. Scans the list of DTF and ACB addresses, handling each item 
in the list in line. When the OPEN macro expands, register 


Simulating Non-CMS Operating Environments'9 161 


Licensed Material--Property of IBM 


1 points to the name of the S$$B transient to receive control 
($SBOPEN) and register 0 points to the list of DIF/ACB 
addresses to be opened. 


2. When an ACB is encountered in the table, control is passed 
directly to the VSAM OPEN routine, $S$BOVSAM. The VSAM 
routine is responsible for opening the file and returning 
control to DMSBOP. 


3. When a DIF is encountered in the table for nondisk files, 
DMSBOP itself handles the OPEN: 


a. For reader/punch files (DTFCD), the OPEN bit in the DTF 
table is turned on. 


b. For printer files (CDTFPR), if two IOAREAS are specified, 
the IOREG is loaded with the address of the appropriate 
IOAREA. Next, the PUB index byte associated with the 
logical unit specified in the DTF is checked to ensure 
that a physical device has been assigned and the PUB 
device code is then analyzed. The OPEN bit in the DTF 
table is then turned on. 


For console files (DIFCN), no OPEN logic is required. 


d. For tape files (DTFMT), the PUB device type code must 
specify TAPE. If an IOREG is specified (for output 
tapes only), the address of the appropriate IOAREA is 
placed in it. For input files, there is separate 
processing for tapes with standard label, nonstandard 
label, and no label. For output tapes, both tape data 
files and work tape files are treated as no label tapes. 


4. For disk files, DMSBOP simulates the function of the VSE 
transient SS$BOSFBL. DMSBOP sets up in the CMSBAM DCSS the 
input parameters and data areas required by the simulated 
VSE SAM routines. Control is then passed to the CMSBAM DCSS 
by placing the address of S$IJJGTOP (the SAM OPEN/CLOSE 
phase) in the problem program save area PSW and exiting via 
sve ll. 


5. DTFDI and DIFCP are device-independent DIFs. Processing is 
as above depending upon the type of physical unit to which 
the DTFs are assigned. 


6. If no disk DTFs are encountered, DMSBOP opens all files in 
the table and returns control to the problem program via SVC 
ll. If a disk DTF is encountered, DMSBOP exits as described 
above in step 4 for disk files. 


7. If errors are encountered during DMSBOP processing, an error 
message is issued and return is made via SVC 6 


Closing Files Associated With DTFs 


Cpening and Closing 


DMSCLS is the CMS/DOS routine that processes CLOSE requests. 
Its logic is analogous to that of DMSBOP, the OPEN routine 
described above: when CLOSE expands, register 1 points to 
SBCLOSE and register 0 points to the list of DTF/ACB addresses. 
The same table containing DTFs and ACBs used to open files is 
also used to close those files. Each entry in the table is 
processed as it occurs, with control passing to a VSAM CLOSE 
routine (SSBCVSAM) when an ACB is encountered. The OPEN bit is 
then turned off. 


Files Associated With Disk DTFSsS 


The OPEN and CLOSE functions for disk DIFs are performed by the 
simulated VSE SAM routines located in the CMSBAM DCSS. 


These routines normally issue the LABEL macro to obtain 
DLBL/EXTENT information from the VSE label area, and issue the 
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OVTOC, PVTOC, and CVTOC macros to obtain VTOC information. 
These macros require special handling in CMS/DOS. Processing is 
as follows: 


1. DMSLAB CLABEL macro support) -- CMS/DOS does not support the 
label information area in the same manner as VSE. CMS/DOS 
keeps similar information in the DOSCB for the file. 

CMS/DOS intercepts invocations of the LABEL macro and passes 
control to DMSLAB. DMSLAB obtains the appropriate 
information from the DOSCB and builds the BLDL/EXTENT 
record. The DLBL/EXTENT record is then returned to the SAM 
routines in CMSBAM. Only the GETLBL and GETNXL functions of 
the LABEL macro are supported. All other functions result 
in an error return code to the SAM routines in CMSBAM. 


2. DMSCVH COVTOC, PVTOC, and CYTOC macro support) ~~ In VSE 
these macros are normally handled by the Common VTOC Handler 
routines. These routines are simulated in CMSBAM and are 
used when accessing the VTOC on an OS or DOS formatted disk. 
However, when these macros are issued for a file on a CMS 
formatted disk, DMSCVH must simulate the appropriate 
function because CMS formatted disks do not contain a VTOC. 
VTOC functions simulated by DMSCVH are as follows: 


OVTOC 
PVTOC 


~ open VTOC 

- read format 1 label by name 
PVTOC - read format 1 label by address 
PVTOC - write format 1 label in any slot 
PVTOC - write format 1 label by address 
PVTOC - check for file overlap 

PVTOC - scratch file 

CVTOC -~ close VTOC 


Any other requested VTOC functions is regarded as an error 
and the program is canceled via SVC 6 


3. When the SAM routines in CMSBAM complete processing, they 
exit via an SVC 2 to $SBOSVLT. The functions of this 
transient are simulated within CMS/DOS by the DMSVLT module. 
Obtained storage areas are returned and other clean-up 
functions are performed. DMSVLT exits in one of two 
different ways: 


e If there are no more DTFs to process, control is 
returned to the problem program via SVC ll. 


e If there are more DTFs to process, an SVC 2 is issued to 
the appropriate $$B transient. Then, DMSBOP or DMSCLS 
is eventually invoked to process the remaining DTFs. 


CONTENTS OF THE CMSBAM DCSS 


Several VSE functions are supported within the CMSBAM DCSS as 
simulated VSE phases. The simulated VSE phases and their 
functions are as follows: 


SIJJGTOP performs OPEN and CLOSE functions for all disk DTFs 
CDTFSD, DTFDI, and DTFCP). 


SIJJHCVH performs VTOC access functions for all. disks in DOS 
format. 


SIJBLBSL performs I/O operations to the VSE source statement 
library for the VSE compilers and the ESERV utility 
program. The compilers invoke this phase via the 
DTFSL macro. ESERV invokes this phase indirectly via 
the LBRFIND and LBRGET macros. 


DMSLBR simulates the VSE internal macros LBROPEN, LBRFIND, 
and LBRGET to the extent required by the VSE ESERV 
utility program. SIJBLBSL is invoked to perform I7/0 
operations to the VSE source statement library when 
appropriate. 
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SIJBLKMD performs the VSE lookaside function as required by 


VSE/VSAM. 
Eight VSE logic modules and two VSE SAM service routines are ; 
also simulated as VSE phases. The logic modules handle I/O 


macros (GET, PUT, POINT, etc.) for SAM files as issued by the 
user's program. The Logic modules and the specific type of SAM 
file they are associated with are as follows: 


SIJGXSDF DTFSD fixed length record data files on DOS formatted 
FB-512 devices assigned to nonSYSFIL logical units. 


SIJGXSDU DTFSD undefined record data files on DOS formatted and 
a Bae disks assigned to nonSYSFIL logical 
units. 


SIJGXSDV DTFSD variable length record data files on DOS 
noe accel FB-512 devices assigned to nonSYSFIL logical 
units. 


SIJGXSDW DTFSD work files on DOS formatted and CMS formatted 
disks assigned to nonSYSFIL logical units. 


SIJGXSVI DTFSD variable length record data files on CMS 
formatted and DOS formatted FB-512 device, or CMS 
li CKD davices assigned to nonSYSFIL logical 
units. 


SIJGXSFI DTFSD fixed length record data files on CMS formatted 
and DOS formatted FB-512 device, or CMS formatted CKD 
devices. 


SIJUGXCP DTFCP files except for files on DOS formatted FB-512 
devices assigned to SYSFIL logical units. 


S$IJGXDI DTFDI files except for files on DOS formatted FB-512 
devices assigned to SYSFIL logical units. ; 


SYSFIL logical units are not supported for use with DOS 
formatted FB-512 devices in CMS/DOS. SYSFIL logical units 
refers collectively to logical units SYSRDR, SYSIPT, SYSLST, and 
SYSPCH. 


The SAM service routines issue the actual I/0 channel programs 
for SAM files. The functions they perform are as follows: 


SIJGXSSR issues I/O operations for DOS formatted FB-512 
devices. 


SIJGXSRI issues I/O operations for all CMS formatted disks 
(FB-512 or CKD) and for DOS formatted CKD devices. 


PROCESS CMS/DOS EXECUTION-RELATED CONTROL COMMANDS 


The CMS/DOS FETCH and DOSLKED commands simulate the operation of 
the VSE fetch routines and the VSE Linkage Editor. The three 
CMS modules that perform this simulation are: 


DMSFET Provide an interface to interpret the DOS FETCH command 
line and execute the phase, if START is specified on the 
command line. 


DMSFCH Bring into storage a specified phase from a system or 
private core-image library or from a CMS DOSLIB library. 


DMSDLK Link edit the relocatable output of the CMS/DOS language 
translators to create executable programs. 
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DMSFET and DMSFCH -- Bring a Phase into Storage for Execution 


The VSE FETCH function is simulated by CMS modules DMSFET and 
DMSFCH. The main control block used during a FETCH operation is 
FCHSECT, which contains addressing information required for I/0 
operations. 


The FETCH command line invokes module DMSFET. This module first 
validates the command line and issues a FILEDEF for the DOSLIB 
file. It then issues a FILEDEF for a DOSLIB file. DMSFET then 
issues a VSE SVC 4, which invokes the module DMSFCH to perform 
the actual FETCH operation. 


DMSFCH first determines where the phase to be fetched resides. 
The search order is private core-image library, DOSLIB, system 
core-image library. If the phase is not found in any of these 
libraries, DMSFCH assumes that the FETCH is for a phase in a 
system or private core-image library. To find a DOSLIB library 
member, OS OPEN and FIND macros are issued (SVC 19 and 18). 


When the member is found, OS READ and CHECK macros are issued to 
read the first record of the file (the member directory). This 
Selah contains the number of text blocks and the length of the 
member. | 


All addressing information is stored in FCHSECT and the text 
blocks in that phase are read into storage. If the read is from 
a CMS disk, issue the 0S READ and CHECK macros to read the data. 
If the read is from a DOS disk, first determine whether this is 
the first read for the CMS/DOS discontiguous shared segment 
(DCSS). If this is the case, CCW information is relocated to 
ensure that the DCSS code is reentrant. For all reads for a DOS 
disk, a CP READ DIAG instruction is issued. When the entire 
file is read, it is relocated Cif it is relocatable). 


If a DOSLIB is open, close it using an OS SVC 20 and return 
control to DMSFET. DMSFET then checks to see whether START is 
specified and, if so, an SVC 202 is issued for the CMS START 
command to execute the loaded file. 


When all FETCH processing is complete, control returns to the 
CMS command handler, DMSITS. 


DMSDLK -- Simulate the Functions of the VSE Linkage Editor 


CMS simulation of the VSE Linkage Editor function directly 
parallels the Release 1 implementation of that function. For 
detailed information on the logic of the function, see the 
publication IBM DOS/VSE Linka Editor Logic, SY33-8556. 


The modules that comprise the VSE Linkage Editor are prefixed by 
the letters IJB and are separate CSECTs. All of these CSECTs 
have counterparts contained within the one CMS module, DMSDLK. 
They are treated as subroutines within that module, but perform 
the same functions as their independent VSE counterparts and 
have been named using the same naming conventions as the VSE 
CSECTs. For example, the IJBESD CSECT in VSE is paralleled by 
the CMS DMSDLK subroutine DLKESD. 


A brief description of the logic follows. The CMS/DOS DOSLKED 
command invokes the module DMSDLK, which is entered at 
subroutine DLKINL. DLKINL performs initialization and is later 
overlaid by the text buffer and the linkage editor tables. 
DLKINL starts to read from a DOSLNK file and processes ACTION 
statements, if there are any. 


On encountering the first non-ACTION card (Cor if there is no 
DOSLNK file), the main flow is entered. Depending on the input 
on the DOSLNK or the TEXT file, records from either of those 
files may be read or records from a relocatable library may be 
read. The type of card image read determines the subroutine to 
which control is given for further processing. 
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An ENTRY card indicates the end of the input to the linkage 
editor. At this point, a map is produced by subroutine DLKMAP. 
DLKRLD is then entered to finish the editing of object modules 
by relocating the address constants. If the phases are to be 
relocatable, relocation information is added to the output on 
the DOSLIB. Updating of the DOSLIB library is performed by 
DLKCAT using the OS STOW macro. 


A significant deviation from VSE code is the use of OS macros, 
in some instances, rather than VSE macros. To take advantage of 
CMS support of partitioned data sets, the OS OPEN, FIND, READ, 
CHECK, and CLOSE macros are issued rather then their VSE 
counterparts. 


SIMULATE VSE SVC FUNCTIONS 


All SVC functions supported for CMS/DOS are handled by the 
following CMS modules: 


DMSDOS 
DMSETR 
DMS GMF 
DMSGTM 
DMSGVE 
DMSLCK 
DMSLDF 
DMSLIC 
DMSMCM 
DMSRPG 
DMSSTX 
DMSSUB 
DMSSVL 
DMSVIS 
DMSXCP 


DMSDOS receives control from DMSITS Cthe CMS SVC handler) when 
that routine intercepts a DOS SVC code and finds that the DOSSVC 
flag in DOSFLAGS is set in NUCON. 


DMSDOS acquires the specified SVC code from the OLDPSW field of 
the current SVC save area. Using this code, DMSDOS computes the 
address of the routine where the SVC is to be handled. 


Many CMS/DOS routines Cincluding DMSDOS) are contained ina 
discontiguous shared segment (DCSS). Most SVC codes are 
executed within DMSDOS, but some are in separate modules 
external to DMSDOS. If the SVC code requested is external to 
DMSDOS, its address is computed using a table called DCSSTAB. 
If the code requested is executed within DMSDOS, the table 
SVCTAB is used to compute the address of the code to handle the 
SVC. Figure 30 on page 167 lists the CMS modules that handle 
SVC functions supported in CMS/DOS. 
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Figure 30. CMS Modules Handling SVC Functions Supported in CMS/DOS 
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Figure 31 shows the VSE SVCs and their support in CMS/DOS 

simulation routines, the name of the macro that invokes a given 

SVC code, and a brief statement describing how the SVC function , 
is performed. } 


Functions SVC No. 
Macro Dec Hex 


EXCP00 Used to read from CMS or DO0S/0S formatted disk. 
The CCW's are converted to appropriate CMS I/0 
requests Cex., RDBUF/WRBUF, CARDRD/CARDPH, etc.). 
The CCB or IORB is posted according to the CMS return 
information. DMSDOS will call CMSXCP routine to 
perform the I/0 operation. If a non-zero return code 
is returned from DMSXCP, a cancel is done. I/0 
requests to DOS disks are handled using CP DIAGNOSE 
instructions. 
FETCH 1 1 Used to bring a problem program phase into user 
storage, and to start execution of the phase if the 
| phase was found. Operand SYS=YES is not supported. 
If the user did specify a directory list, a call to 
DMSFCH is made. Otherwise, DMSDOS will build a 
directory list using the specified phase name. Once 
the directory list is prepared, a call to DMSFCH is 
made. Upon return from DMSFCH, if the phase was 
found, the entry point address of the phase is saved 
in the 'SVC* save area oldpsw so that upon return to 
CMS, DMSITS will then give control to the phase just 
loaded. If upon return from DMSFCH there were any 
errors, a cancel is done. If the phase was not 
found, a message is issued and a cancel is done. 
FETCH Used to bring a $$B-transient phase into the CMS 
transient area (Cor if the phase is in the CMSDOS 
segment, not to load it), and start execution of the 
| phase if the phase was found. Operand SYS=YES is not 
supported. 
A search is made through the loaded segment(s) in an 
attempt to locate the specified transient. If the 
phase is found in one of the segments, a call to 
DMSFCH is not needed. If the phase was not found, a 
call to DMSFCH is made ina similar way as in SVC l 
above. Once the transient entry point is obtained 
(from storage or loaded), the address is saved in the 
SVC save area (as above SVC 1) so that DMSITS gives 
immediate control to the phase wanted. Errors or not 
found conditions are handled as above in SVC l. 


FORCE Not supported, see note 2. 
DEQUEUE 


Figure 31 (Part 1 of 11). SVC Support Routines and their Operation 
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Functions SVC No. 
Macro Dec Hex 


C LOAD Used to bring a problem program phase into user 
storage, and return the caller the entry point 
address of the phase just loaded. Operand SYS=YES is 
not supported. 


Bs) 
Ps) 


Loading of the requested phase is done exactly as 
FETCH (SVC 1) calling DMSFCH. Any errors returned 
from DMSFCH are processed exactly as in fetch. A 
difference between FETCH (SVC 1) and LOAD (SVC 4), is 
that upon return from DMSFCH, assuming there are no 
errors, the user's registers 0 and 1 are updated to 
contain the address of the directory list (for the 
user to test if the phase was found), and the entry 
point address of the phase, respectively. If IJBSIA 
is being loaded, the address of DMSLAB is returned. 
If SIJJHCVA CCommon VTOC handler) is being loaded, 
the address of DMSCVH is returned. 

MVCOM Provides the user with a means of altering positions 
12 through 23 of the partition communications region 
(BGCOM). 


Before moving the specified information, a test is 
made to ensure that the range Cuser's start address, 
plus length of field to move) will not exceed the 
allowed range. Once the specified range is found to 
be within the allowed limits, the user's specified 
information is moved to the partition communications 
region. 

CANCEL Cancels a VSE session either by a VSE program 
request, or by request from any of tha CMS routines 
handling CMS/DOS. 


c 


00 ~ 
oe ~ 


Cancel will issue the message ‘JOB CANCELLED DUE TO 
PROGRAM REQUEST'. A test will be made to see if the 
value of register 15 upon entry to cancel is below 
256. If below, the value in register 15 will be the 
return code to CMS. If equal or greater, a special 
return code of 101 will be used to denote that the 
cancel was issued from a user program Creturn code of 
101 is not used for CMS error messages). Processing 
then continues using the ‘EQJ'’ code. 

WAIT Used to wait on a CCB, IORB, ECB, or TECB (note that 
CMS/DOS does not support ECBs or TECBs). CCBs are 
always posted by the DMSXCP routine before returning 
to the caller. 


The WAIT support under CMS/DOS will effectively be a 
branch to the CMS/DOS POST routine. 

CONTROL Temporarily return control from a $$B-transient to 
the problem program. 


If a $$B-transient has to temporarily give control to 
the problem program, the $$B-transient will issue an 
SVC 8 passing in register 0 the address of the 
problem program gaining control. SVC 8 routine will 
store this address in the SVC work area oldpsw, and 
return back to CMS SVC handler CDMSITS). 


Figure 31 (Part 2 of 11). SVC Support Routines and their Operation 
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Functions SVC No. 
Macro Dec Hex Support 


LBRET Return to a $$B-transient after an SVC 8 was issued 
to give control to the problem program. 
The address saved before (SVC 8 above) is stored in 
the SVC work area oldpsw, so that when DMSDOS returns 
to the CMS SVC handler, control is given to the 
$$B-transient that issued the SVC 8. 


SET 10 A No operation, successful return code of 0 is given in 
TIMER register 15. See note l. 

TRANS. ll B Return from a $$B-transient to the calling problem 
RETURN program. 


The address saved when the initial SVC 2 (fetch a 
$$B-transient) was issued, is stored in the CMS's SVC 
work area oldpsw. Now, when DMSDOS returns to the 
CMS's SVC handler, control will return to the problem 
program that issued the SVC 2 calling the 
$$B-transient. 


JOB CTL. l2 C 
"AND'* 

"AND”™ SVC 

12 


Resets flags to 0 in the linkage control byte in 
BGCOM (communication region). If register 1 equals 
0, SVC 12 has another meaning. Bit 5 of JCSW4 
CCOMREG byte 59) is turned off. 


If register 1 contains a nonzero value, the function 
depends on bit 8 of this register. If bit 8 is 0, 
this SVC supplies supervisory support to reset flags 
in the linkage control byte (displacement 57 in BGCOM 
- communication region). The user has provided the 
address of a mask (1 byte) in register 1. An ‘AND' 
operation of the mask with the linkage control byte 
is performed. If bit 8 of register 1 is one, this 
SVC supplies the supervisory support to reset flags 
in a specified byte of BGCOM (communication region). 
The user has provided a displacement in byte 2 anda 
mask in byte 3 of register 1. An '‘'AND' operation of 
the mask byte with the specified displacement in the 
partition communication region is performed. 


JC FLAGS Not supported. See note 2. 


EOJ 14 E Normally terminates execution of a problem program. 
The last SVC save work area is unstacked. Cleanup is 
done by: 

1. Clearing the CMS DOSLIB CMSCB 

2. Resetting the JOBNAME in BGCOM 

3. Unassigning all temporary device assignments 
The latest return code is loaded into register 15, 
and control returns to DMSITS CCMSRET). 


SYSIO Not: ‘Supported. Sea nota 2. 


Figure 31 (Part 3 of 11). SVC Support Routines and their Operation 
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Macro Dec Hex 
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Establish or terminate linkage to a user's program 
check routine. 


Locate the appropriate PC option table entry. If the 
contents of register 0 is zero (terminate linkage), 
determine if PC routine is active. If the PC routine 
address in PC option table is negative, terminate 
linkage by storing zero in routine address field of 
PC option table. If the routine is not active 
presently, store zeros in PC routine address field 
and savearea address field in PC option table. If 
register 0 is not zero, the address of the PC routine 
and the savearea address is passed to the STXIT 
macro. If a STXIT PC routine is active, the 
complement of the new routine address is placed in 
the PC option table. If no STXIT PC routine is 
active, the new PC routine address and savearea 
address are stored in the PC option table. 


Used to provide supervisory support for the EXIT 
macro. SVC 17 provides a return from the user's PC 
routine to the next sequential instruction in the 
program that was interrupted due to a program check. 


Locates the appropriate PC option table entry and 
restores user's registers and PSW. Stores the 
address of the PC routine in the PC option table 
returns to the next sequential instruction in the 
program that was interrupted. 


No operation, successful return code of 0 is given in 
register 15. See note 


Not supported See note 2 


e 
_ 
e 

e 


No operation, successful return code of 0 is given in 
register 15. See note l 


Oc EXIT — Not supported. See note 2. 


No operation, tebatchatae return code of 0 is given in 
register 15. See note 


LOAD Not supported. See note 2. 
HEADER 


No operation, successful return code of 0 is given in 
register 15. See note l. 


HALT I70 —- Not supported. See note 2. 


“e | | 


Validate address limits. The upper address must be 
specified in general register 2 and the lower address 
must be specified in general register l. 


First the lower address must not be negative. An 


error message DMSDOSO05E is issued if it is. Second, 
the high address cannot be negative. If it is, the 
same error messages is issued. If the low or high 
address is greater than the end of partition address 
in BGCOM, the same error message is issued. 
Otherwise, control returns to the caller. 


LP a 27 1B Not supported. See note 2. 
/ | 


( Figure 31 (Part 4 of 11). 
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SVC No. 
Macro Dec Hex 
Tae exit 2016 


COMRG Used to provide the caller with the address of the 
partition communications region. 
DMSDOS will provide the caller with the address of 
the partition communications region, in the user's 
register l. 

GETIME 34 22 Provides support for the GETIME macro. SVC 34 
updates the date field in the communications region. 
The GMT operand is not supported. 


HOLD No operation, successful return code of 09 is given in 
register 15. See note l. 

FREE 36 24 No operation. Successful return code of 0 is given 
in register 15. See note l. 


AB STXIT 37 25 Establish or terminate linkage to a user's abnormal 
termination routine. 
Supported for OPTION=DUMP or NODUMP. 
Locate the appropriate AB option table entry. If RO 

| 7S zero and the AB routine is inactive, then 

terminate linkage. Otherwise, if the AB routine is 
active (bit 0 of the AB routine address is on), then 
cancel the program. 
If RO is not zero and the AB routine is active, 
cancel the program. Otherwise, validate the save 
area address (must be at least X'20000' and not 
greater than the partition end), and store the AB 
routine and save area addresses in the AB option 
table. 


ATTACH 38 26 Not supported. See note 2. 
DETACH | 39 a7 | Hot <upported: “See motace: 


39 27 
POST 40 28 Used to post an ECB, IORB, TECB, or CCB. Byte 2, bit 
0 of the specified control block will be turned ‘on' 
by DMSDOS. 


41 29 No operation, successful return code of 0 is given in 
register 15. See note l. 


~— 42 2A No operation, successful return code of 0 is given in 


register 15. See note l. 


asa [Reserved OSC 


43 2B 
UNIT 44 2c Not supported. See note 2. 
CHECKS 


Figure 31 (Part 5 of 11). SVC Support Routines and their Operation 
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Function/ SVC No. 
( Macro Dec Hex 
EMULATOR 45 2D Not supported. See note 2. 
INTERF. 


OLTEP 4&6 2E Not supported. See note 2. 
CRT TRANS 48 30 Not supported. See note 2. 


CHANNEL 49 31 Not supported. See note 2. 
PROG. 


LIocs Issued by a logical IOCS routine when the LIOCS is 
DIAG. called to perform an operation the LIOCS was not 
generated to perform. 
The error message ‘unsupported function in a LIOCS 
routine’ will be issued, and the session will then be 
terminated. 


RETURN 51 33 Not supported. See note 2. 

HEADER 

TTIMER No operation. Successful return code of 0 is given n 
register 15. See note 1. Register 0 is also 
cleared. 


[wan exit [335 | Not supported, Sea note a 
[Trower [se se | Not surorted. Seo note 2. 
Trower [57 39 | Wot supported. Sea note 2 


SUPVR. Not supported. See note 2. 
INTERF. 
EOJ Not supported. See note 2. 
INTERF. 


GETADR 60 3c Not supported. See note 2. 


GETVIS 61 3D Used by VSAM to obtain free storage for scratch use 
or for obtaining an area into which a relocatable 
VSAM program may be loaded. 

A free storage subroutine similar to that in the 
DMSSMN routine is called to obtain the needed space 
(from the user area). If successful, the address is 
returned in register 1, and register 15 is cleared. 
If the request cannot be satisfied, a return code of 
12 is passed back in register 15. 

The "PAGE', "POOL', and 'SVA* GETVIS options are 
ignored. 


Figure 31 (Part 6 of 11). SVC Support Routines and their Operation 
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Function SVC No. 
Macro Dec Hex 


FREEVIS 62 3E Used to return the free storage obtained via an 
earlier GETVIS call. 
The free storage subroutine similar to that in the 
DMSSMN routine is called to return the area 
designated by register 1. All complete pages (4K 
bytes) associated with the returned storage are 
gt alae by issuing a DIAGNOSE code X'10' instruction 
o : 


The USE/RELEASE function has been replaced by SVC 110 
CLOCK/UNLOCK) for serially controlling system 
resources. All SVC 63 and 64 requests are mapped 
into SVC 110 requests respectively. Return code 
previously associated with USE/RELEASE under CMS/DOS 
are maintained. 


RELEASE Reference SVC 63. 


CDLOAD 41 Used to load a relocatable VSAM phase into storage 
unless the program has already been loaded. 
If an anchor table is available, it is searched for 
the given phase; if found, its load point, entry 
point, and length are returned in the caller's 
register 0, 1, and 14 respectively, with register 15 
set to 0. 
If not, DMSFCH is called to find the given phase; if 
found in a discontinuous shared segment, register 0, 
1, and 14 are loaded as above and return made. 
If the phase was found but is not loaded, storage is 
obtained (Cif available) from the GETVIS SVC; DMSFCH 
is called again to load the program into the storage 
area just obtained. An anchor table is built in the 
user area Cunless one already exists), the 
appropriate entries made, and registers 0, 1, and 14 
loaded as above, with return to caller. 
If the program cannot be found, or if storage is 
unavailable for either loading the program or for 
building the anchor table, an error code 22 (X'16') 
is returned to the caller in register 15. 


Used by a problem program to find out if the program 
is running in real or virtual mode. 
The caller's register 0 will be zeroed to indicate 
that the program 1s running in virtual mode. 

PFIX 67 43 No operation, successful return code of 0 is given in 
register 15. See note l. 


68 44 No operation. Successful return code of 0 is given 
in register 15. See note l. 
REALAD | 69 45 Not supported. See note 2. | 
VIRTAD 70 46 Not supported. See note 2. 


SETPFA 71 47 No operation. Successful return code of 0 is given 
in register 15. See note l. 


Figure 31 (Part 7 of 11). SVC Support Routines and their Operation 
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Functions SVC No. 
Macro Dec Hex Support 
Cc GETCBUF/ Not supported. See note 2. 


72 48 
FREECBUF 
SETAPP 73 49 Not supported. See note 2. 
PAGE FIX 74 GA Not supported. See note 2. 
SECTVAL 75 4B Used by VSAM I/0 routines Cex., IKQIOA) to obtain a 
sector number for a 3330, 3330-11, 3340, or 3350 
device. 


The appropriate sector value is calculated from the 
input data supplied by the user's register 0 and l. 
If the calculation is successful, the sector number 
(from 0 to 127) is returned in register 0. 


If any errors were detected, the noop set~-sector 
value of 255 (X'FF*) is returned. 


[onan | 7848 | Wot surported. Sew note 2. 
Tuiwnce [8252 | Wot surported. Sew note 2. 
| aitocate [2353 Not suprorted. Seo note 2. 


RELPAGE &5 55 Provides support for the RELPAG macro. At entry 


register 1 points to a list of 8-byte storage 
FCEPGOUT 86 56 No operation. Successful return code of 0 is given 
In register 15. See note l. 


description areas. Each entry contains the beginning 
Figure 31 (Part 8 of 11). SVC Support Routines and their Operation 


address and the length 1 of an area to be released. 

A nonzero byte following an entry indicates the end 
of the list. An area is released only if it contains 
at least a full CP page (4K bytes). Pages are 
released when the virtual machine calls CP via 
DIAGNOSE code X'10'. On return register 15 holds the 
return code as follows: 


register 15 = all areas have been released 


register 15 = one or more negative area lengths were 
specified. 


register 15 = one or more pages to be released were 
outside the user storage area. 


16 at least one entry contains a 
beginning address outside the user 
storage area. 


register 15 


C 
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Function/ SVC No. 
Macro Dec Hex 
87 57 No operation. Successful return code of 0 is given 
in register 15. See note l. 
TPIN 88 58 | Not supported. See note 2. 
TPOUT 89 53 Not supported. See note 2. 


XECBTAB 92 5C Not supported. See note 2. 
XPOST | 93 SD Not-supporteds See note: 
XWAIT } 94 SE Not supported. See note 2. 


AB EXIT 95 5F Exit from abnormal task termination routine and 
continue the task. 
The linkage to either the PC or AB routine is 
reestablished, and the cancel condition is reset by 
clearing the ABEND indication in the partition PIB 
extension. Control is returned to the instruction 
following the exit AB macro. 


TT EXIT 96 60 Not supported. See note 2. 
TT STXIT 97 61 Not supported. See note 2. 


EXTRACT 93 62 Support for EXTRACT macro of VSE. The caller 
requests PUB information, CPUID or, storage boundary 
information. Register 1 on entry points to a 
parmlist. Output is placed in an area provided by 
| caller. 
GETVCE 

pointed to from the parmlist. Register 1 contains a 

pointer to the parmlist on entry. 


MODVCE 101 65 No operation. Successful return code of 0 is given 
in register 15. See note l. 


SYSFIL 103 67 Not supported. See note 2. 
supervisor subsystem. Information returned 15 
LINKAGE 106 6A Not supported. See note 2. 


EXTENT 104 68 No operation. Successful return code of 0 is given 
in register 15. See note l. 
described by the SUPSSID control block. The SUBSID 
Figure 31 (Part 9 of 11). SVC Support Routines and their Operation 


Caller requests device information about a specific 
DASD. Information is returned in an output area 


SUBSID SUBSID.. the "INQUIRY' function is supported for the 
"NOTIFY" and "REMOVE" functions are not supported. 
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Function 
Macro 


Provides macro interface support for system 
information retrieval. The parameters supported are: 


GETFLD: 


field=ppsavar returns problem program save area 
address. 


field=savar returns current save area 
address. 


field=aclose return in register 1, 0 if in 
process, 1 if not. 


field=pcexit returns the pcexit routine 
address and save area in RO and 
Rl, respectively. If the exit 
routine is currently active, bit 


0 in RO is set ON. If no exit is 


defined, it returns 0 in both RO 
and Rl. 


MODFLD: 


field=vsamopen set bit X'08'" in tcb tcbhflags 
byte. 


field=aclose set bit X'10° in tcb tcbflags 
byte. 


All other GETFLD/MODFLD requests are treated as a NOP 
and a return code of 0 is placed in register 15. 


All other SVC107 macro calls are unsupported. The 
error message DMSGMF1215 will be issued and the 
program is canceled. See note 2. 


DATA 108 6C Not supported. See note 2. 
SECURE | 


PAGESTAT 109 6D Not supported. See note 2. 


LOCK/ 110 6E 
UNLOCK 


Figure 31 (Part 10 of 11). 


Used by VSAM to control access to resources. Access 
is maintained in either a ‘shared’ or ‘exclusive’ 
control environment. When DOS is SET ON, counters 
are maintained as well as the type of control for 
each resource in a table (CLOCKTAB) built in free 
storage. All entries not unlocked by the program are 


cleared at both normal and abnormal end-of-job. 


All requests for resource control are passed to SVC 
110 through the DTL macro (Define the Lock). SVC 63 
Peery: are mapped into a dummy DTL and processed by 
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Function/ SVC No. 
Macro Dec Hex Support 


No operation: 

In each case, register 15 is cleared to simulate 
successful operation, and all other registers are 
returned unchanged, unless otherwise noted. 


Not supported: 


For unsupported SVCs, an error message will be 
given, and the SVC will be treated as a "cancel." 


Figure 31 (Part 11 of Il). 


SVC Support Routines and their Operation 


PROCESS CMS/DOS SERVICE COMMANDS 


DMSSRV 


DMSPRV 


DMSRRV 


DMSDSV 


DMSDSL 


ESERV 


Copies books from a system or private source statement 
library to a specified output device. 


Copies VSE procedures from a VSE system procedure 
library to a specified output device. 


Copies modules from a system or private relocatable 
library to a specified output device. 


Lists the directories of VSE private or system 
libraries. 


Deletes members (phases) of a DOSLIB library; compresses 
a peeeGe library; lists the members (phases) of a DOSLIB 
library. 


De-edits, displays or punches, verifies, and updates 
edit assembler macros from the source statement library. 


TERMINATE PROCESSING THE CMS/DOS ENVIRONMENT 


DMSBAB 


DMSITP 
DMSDMP 


Gives control to an abnormal termination routine once 
linkage to such a routine has been established via the 
STXIT AB macro. 


Processes program interrupts and SPIE exits. 


Simulates the $$BDUMP and $$BPDUMP routines; issues a CP 
DUMP command directing the dump to an offline printer. 
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FOR MISCELLANEOUS CMS FUNCTION 


CMS BATCH FACILI 


Y 


The CMS Batch Facility is a function of CMS. It provides a way 
of entering individual user jobs through an active CMS machine 
from the virtual card reader rather than from the console. The 
batch facility reissues the IPL command after each job. 


The CMS Batch Facility consists of two modules: DMSBTB, the 
bootstrap routine (a nonrelocatable CMS module file) and DMSBTP, 
the processor routine (a relocatable CMS text file that runs 
free storage). 


GENERAL OPERATION OF DMSBTB 


The bootstrap module, DMSBTB, loads the processor routine DMSBIP 
and the user exit routines BATEXIT1] and BATEXIT2 Cif they exist) 
into free storage. 


DMSBTB first ensures that DMSINS CCMS initialization) has set 
the BATRUN and BATLOAD flags on in the CMS nucleus constant area 
indicating that either an explicit batch initial program load 
command has been issued or that the CMSBATCH command has been 
issued immediately after initial program load has taken place. 
If not, error message DMSBTBIlO1E is typed and the batch console 
returns to a normal CMS interactive environment. STATE (CDMSSTT) 
is then called to confirm the existence of the processor file 
DMSBTP TEXT. If the file does not exist, error message 
DMSTBTLOOE ts typed and the batch console returns to the CMS 
interactive environment. 


Using the “state” copy of the file status table (FST) for 
DMSBTP, DMSBTB computes the size of DMSBTP TEXT file by 
multiplying the logical record length by the number of logical 
records (no DS constants). <A free storage request is made for 
the size of DMSBTP, and the address of the routine is then 
stored at ABATPROC in the NUCON area of the CMS nucleus. 


The existence of the user exit routines is determined by STATE. 
If they exist, their sizes are included in the request for free 
storage. 


The free storage address is translated into graphic hexadecimal — 
format, and the CMS LOAD command is issued to load the DMSBITP 
TEXT file into the reserved free storage area. The user exit 
routines, BATEXIT1 TEXT and BATEXIT2 TEXT are also loaded at 
this time. If these files do not exist, an unresolved external 
reference error code is returned by the loader, but the error 
code is ignored by DMSBTB because these routines are optional. 
If an error Cother than unresolved names) occurs, error message 
DMSBTBIOIE is typed and the batch console returns to the CMS 
interactive environment. 


The loader tables are searched for the address of the ABEND 
entry point DMSBTPAB in the loaded batch processor. When the 
entry is found, its address and that of entry DMSBTPLM are 
stored in ABATABND and the ABATLIMT respectively, in the NUCON 
area of the CMS nucleus. If the ABEND entry point is not found 
in the tables, error message DMSBTB1O1LE is typed and the batch 
console returns to the CMS interactive environment. 


The BATLGAD flag is set off to show that DMSBTP has been loaded, 
the BATNOEX flag is set on to prevent user job execution until 
DMSBTP encounters a /JOB card, and finally, control is returned 
to the command processor DMSINT. 
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If an error message is issued, DMSERR is called to type the 
message, and the BATRUN and BATLOAD flags are set off before 
control is returned to CMS. This allows the normal CMS 
interaction to resume. 


GENERAL OPERATION OF DMSBTP 


The batch processor module DMSBTP simulates the function of the 
CMS console read module, DMSCRD. This is accomplished by 
issuing reads to the virtual card reader, formatting the 
card-image record to resemble a console record, and returning 
control to CMS to process the command (Cor data) request. DMSBTP 
also performs reads to the console stack if the stack is not 
empty, checks for and processes the /JOB card, ensuring that it 
is the first record in the user job, traps all CP commands to 
maintain system integrity, and performs job initialization, 
cleanup, and job recovery. 


Upon receiving control, DMSBTP checks the BATCPEX flag in NUCON. 
If the flag is set on, control was received from DMSCPF and a 
branch is made to the CP trap routine to verify that the command 
is allowable under batch. The function of that routine is 
described later. If the BATCPEX flag is off, control was 
received from DMSCRD (Cconsole read module) and DMSBTP checks for 
finished reads in the real batch console stack. If the number 
of finished reads is not zero, control is returned to DMSCRD to 
process the real console finished (stacked) reads. If the 
number of finished reads is zero, a record is read from the 
batch virtual card reader into the CARD buffer via an SVC call 
to CARDRD (DMSCIO). The record in the CARD buffer is typed on 
the console via the WRTERM macro. If the BATMOVE flag is set on 
(MOVEFILE executing from the console), the records in the file 
are not typed on the console. 


The record in the reader buffer is scanned to compute its length 
with trailing blanks deleted. It is then moved to the CMS 
console read buffer, and the computed length is stored in the 
original DMSCRD parameter list, whose address is passed by 
DMSCRD when it initially passes control to DMSBITP. 


If the first user record is not a /JOB card, error message 
DMSBTP1LOSE is typed and normal cleanup is performed with the 
BATTERM flag set on. This flag prevents another initial program 
load, since it is not needed at this time. Reads to the card 
reader are then issued until the next /JOB card is found. 


If the first record is a /JOB card, DMSBTP branches to its /JOB 
card processing routine which calls DMSSCNN via a BALR. A check 
is made for the existence of the userid and account number on 
the card. If the fields exist, a CP DIAGNOSE X'4C' is issued to 
start accounting recording for that userid and account number. 
If an error is returned from CP denoting an invalid userid or if 
the userid or account number fields were missing on the /JOB 
card, error message DMSBTP1O6E is typed and normal cleanup is 
performed with the BATTERM flag set on. 


The jobname, if provided on the /JOB card, is saved anda 
message is issued via SVC to inform the source userid that the 
job has started. The spooling devices are closed and respooled 
for continuous output, a CP QUERY FILES command is issued for 
information purposes, and the implied CP function under CMS is 
disabled and the protection feature set off via SVC calls to SET 
CDMSSET). The BATPROF EXEC is executed via an SVC to EXEC. The 
BATNOEX flag, which is set by DMSBTB to suppress user job 
execution until the /JOB card is detected, is set off. The 
BATUSEX flag is set on (Cfor DMSCPF) to signal the start of the 
actual user job, and a branch is taken to read the next card 
from the reader file (user job). 


After reading the /JOB card, DMSBTP continues reading and checks 
for a /%® card, a /SET card, or a CP command. If a card is none 
of these, DMSBTP passes control back to the command processor 
DMSINT for processing of the command Cor data). 
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If a /*% card is read and it is the first card of the new job, it 
is assume to be a precautionary measure and thus ignored by 
DMSBTP which then reads the next card. If it is not the first 
card, a check is made for the BATMOVE flag. If the flag is on, 
the /*® card indicates an end-of-file condition for the MOVEFILE 
operation from the console (reader) and is consequently 
translated to a null line for the MOVEFILE command. 


If the BATMOVE flag is not on, the /*® card is an end-of-job 
indicator and an immediate branch is taken to the end-of-job 
routine for cleanup and reloading of CMS batch. 


When a CP command is encountered, DMSBTP branches to a routine 
that first checks a table of CP commands allowable in batch. If 
the command is allowed, a check is made for a reader or other 
spool device in the command line. If the CP command is allowed 
but would alter the status of the batch reader or any spooling 
device or certain disks, or if the command is not allowed at 
a error message DMSBTPLO7E is typed, and the next card is 
read. 


If the CP command is LINK, the device address is stored ina 
table so that DMSBTP can detach all user disk devices at the end 
of the job. 


A CP DETACH command is examined for a device address 
corresponding to the system disk, the IPL disk, the batch 195 
work disk or any spool device. If the device to be detached is 
any of these, error message DMSBTP1O7E is displayed and the next 
card is read. Otherwise, DMSBTP returns control to DMSINT Cor 
aA A the BATCPEX flag is set on) for processing of the 
command. 


When a /SET control card is encountered, the card is checked for 
valid keywords, valid integer values (less than or equal to the 
installation defauit values). If an error is detected, error 
message DMSBTPLO8E is typed. An abnormal termination message is 
also sent to the source userid, and the job is terminated with 
normal cleanup performed. If the control card values are valid; 
the appropriate fields are updated in the user job limit table 
DMSBTPLM and the next card is read. 


If DMSBTP detects a "not ready™ condition at the reader, a 
message is typed at the console stating that batch is waiting 
for reader input. DMSBIP then issues the WAITD macro to wait 
for a reader interrupt. When first detecting the empty reader, 
DMSBTP calls the CP accounting routines via a CP diagnose "4C* 
to charge the wait time to the batch userid. 


If a hard error is detected at the reader, DMSBTP sends an 
"intervention required" message to the system console, branches 
to its abnormal terminal routine, and waits for an interruption 
for the reader by issuing the WAITD macro. 


When a /* card is read (with the BATMOVE flag off) or when the 
end-of-file condition occurs at the reader, DMSBTP branches to 
the cleanup routine that sends the source userid a message 
stating that the job ended normally or abnormally Cif cleaning 
up after an abnormal termination) and turns off the BATUSEX flag 
(for DMSCPF) to signal the end of the user job. CONWAIT 
CDMSCWT) is called via SVC to allow any console I/0 to finish, 
the spooling devices are closed (including the console), and all 
disks that were made available by issuing the CP LINK command 
are returned by issuing the CP DETACH command. 


DMSBTP then relinquishes control by issuing the CP IPL command 
with the PARM BATCH option which loads a new CMS nucleus, and 
the next job is started when CMS attempts its first read to the 
console. 


A branch is made to the CMSBTP routine when DMSBTP itself 
detects an I/0 error at the reader. However, the primary 
purpose of the routine is to receive control not only from 
DMSABN when there is an abnormal termination during the user 
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job, but also from DMSITE, DMSPIO, and DMSCIO when a user job 
exceeds one of the batch job limits (BATXLIM flag is on). This 
routine, entry point DMSBTPAB, calls the CP DUMP routine via 
SVC, and then it branches to the cleanup routine that reloads 
CMS Batch and treats the remainder of the current job as a new 
job with no /JOB card. This has the effect of flushing the 
remainder of the job. This technique is used because batch must 
keep its reader spooled "continuous." Entry point DMSBTPAB is 
also used by the CMS commands that are disabled in CMS batch. 
In this case (BATDCMS flag set on), an error message is 
displayed and control returned to CMS. 


When a CP command is called via an SVC in DMSBTP, the CMS CP 
module (DMSCPF) is actually called to issue the DIAGNOSE 
instruction to invoke the CP command. DMSBTP calls DMSCPF by 
issuing a direct SVC 202 or by issuing the LINEDIT macro with 
the CPCOMM option that generates an SVC 203. 


OTHER CMS MODULES MODIFIED IN CMS BATCH 
Several CMS modules check whether CMS batch is running, and, if 
so, they perform functions associated with batch operation. 
These modules are shown in the following list: 
Module Function Performed for CMS Batch 
DMSINI Passes batch parameters to DMSINS. 
DMSINS Uses batch IPL parameters to reload CMS Batch. 
DMSLDR Loads DMSBTP into free storage. 


DMSCRD Passes control to DMSBTP to read from the reader 
rather than from the console. 


DMSITE Accounts for virtual time used by batch job -~- ABEND 
if over limit. 


DMSPIO Accounts for number of lines printed by batch job -- 
ABEND if over limit. 


DMSCIO Accounts for number of cards punched by batch job -- 
ABEND if over limit. 


DMSABN Passes control to batch ABEND routine in DMSBTP. 


DMSERR Passes control to batch ABEND routine instead of 
entering disabled wait state. 


DMSMVE Turns the BATMOVE flag on and off -- allows batch to 
treat moved blanks as data. 


DMSSET Disabled if batch running, except during batch 
initialization. 


DMSRDC Disabled if batch running. 


DMSCPF Distinguishes between CP command issued by user and by 
batch. 
DMSFLD Disallows reader device specification. 


DMSDSK Disk load not allowed in batch. 
| EXEC 2 AND SYSTEM PRODUCT INTERPRETER PROCESSING 


Three modules process these functions: DMSEXI, DMSEXE, and 
DMSREX. 
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DMSEXI is an interface routine between CMS and either the CMS 
EXEC interpreter, the EXEC 2 interpreter, or the System Product 
Interpreter. DMSEXE is the EXEC 2 interpreter. DMSREX is the 
System Product Interpreter. 


A description of each module's method of operation follows. 


MODULE NAME: DMSEXI 
CALLED BY: DMSEXC for all EXEC functions 
CALLS TO OTHER ROUTINES: 


DMSBRD - 'RDBUF* file system function 
DMSEXT - CMS EXEC processor 

DMSEXE - EXEC 2 processor 

DMSFRE - Get and return free storage 
DMSREX ~- System Product Interpreter 


EXTERNAL REFERENCES: NUCON, IO 
METHOD OF OPERATION: 


DMSEXI is an interface routine between CMS and the three EXEC 
interpreters. 


DMSEXI allows coexistence by routing calls to either the System 
Product Interpreter, the EXEC 2 interpreter, or the CMS EXEC 
interpreter, according to the following rules: 


1. The caller provides an extended-form PLIST, including a file 
block. DMSEXI directs the call to the EXEC 2 interpreter or 
System Product Interpreter. 


2. The specified EXEC file exists, has a valid format, and 
contains the character '/** as the first two non-blank 
characters in the first 255 characters of the first record 
or byte 0 of register 1 is X'05*". DMSEXI directs the calls 
to the System Product Interpreter, after generating a file 
block and copying or building an extended PLIST. 


3. The specified EXEC file exists, has a valid format, and 
contains the word "&TRACE™ within the first 255 bytes of 
line 1 or byte 0 of register 1 is X'O1* or X'OB' anda 
FILEBLOK exists. DMSEXI directs the calls to the EXEC 2 
interpreter, after generating a file block and copying or 
building an extended PLIST. 


G4. DMSEXI directs all other cases to the CMS EXEC interpreter, 
with the original PLIST pointer. 


There 15 one case where DMSEXI must build an untokenized command 
string to pass to DMSEXE: 


e If only a tokenized PLIST is available, DMSEXI builds a 
command string by concatenating the CMS tokens, separating 
each by one blank, with no leading or trailing blanks. 


DMSEXI releases any storage obtained before it called DMSEXE, 
then returns to the main caller with the return code from DMSEXE 
in register 15. 


The format of the extended-form PLIST is: 


PLIST DS OF Calignment) 
Dc ACcommand-verb) 
DC ACparm-string) 
DC ACbyte-following-parm-string) 
DC ACO) or ACfile-block) (the file to be executed) 
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DMSEXE 


The following two lines exist only if a function call: 
DC ACarglist) adlen pairs 
DC AC funret) address to store returned 
data pointer 
The command-verb and the parm~string form a contiguous area: 


COMMAND DC C*'command-verb'* 
DC C’parm-string’ 


Trailing blanks are allowed after the command-verb. 


The format of the file block is: 


FILE DS OF Calignment) 
DC CL&8' filename’ Cor blank) 
DC CL8' filetype’ Cor blank) 
DC CL2'filemode’ Ceg. Al, or blank) 


If the filename contains blanks, CMSEXI will use the first word 
in the argument list (&0) as the filename. 


eee filetype contains blanks, DMSEXI will use a filetype of 
If the filemode is blank, DMSEXI will use the first file with 
the specified filename and filetype, found according to the file 
system search order. 


The format of the file block extension is: 


DC XL2€00000) or XL2(0002) Cnumber of words 
in extension) 


DC ALS CPGMFILE) Caddress of the in-storage 
EXEC 2 descriptor) 
DC AL4¢CPGMEND-PGMFILE) (number of bytes 


in descriptor) 


MODULE NAME: DMSEXE 
CALLED BY: DMSEXI to interpret EXEC 2 statements. 
CALLS TO OTHER ROUTINES: 


DMSERR ~- Write all error messages 


DMSSCN Tokenize strings 

DMSPNT "POINT’ file system function 
DMSSTT "STATE' file system function 
DMSBRD "RDBUF' file system function 


DMSFNS ~- 'FINIS’® file system function 


DMSFRE Get and return free storage 
WAITRD Read from the terminal 
TYPLIN Type on the terminal 

ATTN Stack lines in console stack 


EXTERNAL REFERENCES: NUCON, FST, FVS, ADT 
METHOD OF OPERATION: 


DMSEXE reads lines from disk files, or accepts lines previously 
prepared by the caller and stored in main memory. 


If the lines are EXEC 2 statements, DMSEXE interprets the 
statements. If the lines contain commands, DMSEXE passes the 
commands to CMS command mode or a subcommand environment. 


Execution continues until a statement or command explicitly 
terminates it, or DMSEXE finds a statement error. 
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DMSEXE LOGIC DESCRIPTION: 


Pseudo Code 


Pseudo code is used to describe the logic of portions of DMSEXE. 
This Pseudo code has the following general statements: 


1. 


DO 

statement 

statement 

statement 

END 

"Statement" is either: 
a. A description of an action to be done, or 
b. Another pseudo code statement: 


DO...END, 
IF...THEN...ELSE, 
GOTO, or 

CALL 


If condition THEN statement ELSE statement. 


"Condition™ is a hyphenated sequence of words describing the 
conditions for which the statement after "THEN" is executed. 


Example: IF initial-flag-is-set 
THEN perform initialization 
ELSE indicate error condition 


GOTO label 


Transfer control to the label specified. A label is 
followed by a colon and precedes a statement, or is ona 
line by itself. 


Example: GOTO George 


George: ... 
CALL name 
CALLs the named subroutine. 
DMSEXE General Logic Flow 


After initialization, DMSEXE loops continually, reading 
lines that may contain EXEC 2 statements or commands. The 
logic follows: 


Initialization 
DO forever 
Loop initialization 
IF executing gloop 
THEN DO 
Test condition 
IF condition 
THEN set for top of loop 
ELSE set for exit from &loop 


END 
CALL READSUB (read next line) 
F eof 
THEN IF executing-&loop 
THEN error condition 
ELSE exit 
“ne EXECUTE Cexecute line) 
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READSUB/READLAB 
READSUB is the DMSEXE subroutine that reads the next line. 
READLAB, a secondary entry point to READSUB, reads the next line J 
when scanning forward for labels. 
READSUB reads a line from: 


1. The console - if the console count is non-zero, 


2. The cache - if there is one, and the needed line is there, 
35 *BUF’ - if the needed line is there, or 
4. The file - if none of the above conditions are true. 


If the line is read from the file, and there is a cache, then 
the line is read into the cache. 


READLAB reads a line from; 

1. The cache - if there is one, and the line is there, 
Ze "BUF - if the line is there, or 

3. The file - if none of the above conditions are true. 


If the line is read from the file, and there is a cache, then 
the line is read into the cache. 


In all cases: 
1. A blank and a zero byte are placed at the end of a line, 
2. The file read may be either an in-storage file, or a file 
accessed by calls to file system routines. 
Line Execution 
DMSEXE executes lines according to the following logic: 


EXECUTE: IF comment THEN exit 


IF tracing THEN trace the line 
IF blank-line THEN exit 


IF assignment 
THEN DO 
CALL ASSIGN Cperform assignment) 
Exit 
END 
IF command 
THEN DO 
Pass command to CMS command mode or 
subcommand environment 
Exit 
END 
(Line must be a control-statement: ) 
Look up control-statement word 


IF found 
THEN DO 
GOTO control-statement routine: 
ex. ARGS 
BEGPRINT 
BEGSTACK 
BUFFER 
Exit 
END 


ELSE error Cinvalid statement) 
END EXECUTE 


Assignment Processing 


DMSEXE processes assignment statements according to the J 
following logic: 
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ASSIGN: CALL SUBS (Substitute value of EXEC variable into 
characters 2 through N of target) 
Point to first word after equal sign 
Call GETNEXT 
IF none THEN set null value and exit 
Call GETNEXT 
IF none THEN set value obtained above and exit 


Top-of-loop: 
IF last-word-is-not-an-operation 
THEN error 
Call GETNEXT 
IF none THEN error 
Call GETNEXT 


IF none 
THEN DO 
Do calculation 
Set value 
Exit 
END 
IF function-reference 
THEN DO 
IF not ‘of* THEN error 
IF system-function 
THEN Call appropriate routine 
to evaluate function 
ELSE invoke user function 
Exit 
END 


Do calculation 
GOTO Top-of-loop 


END ASSIGN 
GETNEXT: Get next word 
found 
THEN DO 
Call SUBS 
ar null THEN GOTO GETNEXT 
E 


END GETNEXT 


SUBS: Set pointer to end of word plus one 


SUBSLP: 
Decrement pointer 
IF at-front-of-word THEN exit 
IF not '&*' THEN GOTO SUBSLP 
Calculate hash using last character of name and length 
Scan appropriate variable lookaside chain 


IF found 
THEN DO 
IF not-~at-front-of-chain THEN put at front 
IF predefined-variable 
THEN DO 
CALL predefined variable routine 
and substitute value 
IF at-front-of-word THEN exit 
GOTO SUBSLP 
END 
Substitute value 
IF at-end-of-word THEN exit 
GOTO SUBSLP 
END 
ELSE DO 
IF predefined-name 
THEN DO 


Build variable blocks 
Point block to processing routine 


a routine and substitute value 
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END SUBS 


DMSREX 


ELSE DO 
Build variable block for null 


value 
Substitute null 
D 
IF at-front-of-word THEN exit 


GOTO SUBSLP 
END 


DMSEXI sends EXEC files (files written in the Restructured 
Extended Executor (REXX) language) to DMSREX (System Product 
Interpreter) if the first two non-blank characters in the first 
255 characters of the first record are '/**,. All System Product 
Interpreter processing is done by DMSREX. DMSREX has the 
following CSECTS: 


DMSRCN 


DMSREV 
DMSRFN 
DMSRIN 


DMSRTC 
DMSRVA 
DMSRXE 
DMSREX 
DMSRSF 


Performs character conversion, console I/0, general 
services, and all arithmetic. 


Evaluates expressions. 
Performs all built-in functions. 


Parses input data, controls most execution decisions, 
and passes clauses to DMSRXE for execution. 


Formats and displays trace information. 
Accesses and maintains variables. 
Executes individual clauses. 

Reads the EXEC file and calls DMSRIN. 


Performs additional functions similar to the built-in 
functions 
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This section contains the following information: 


e Module Entry Point Directory 
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Module 
Name 


DMSABN DMSABN Intercepts an abnormal termination CABEND) and 
provides recovery from the ABEND. Entered by a DMKABN 
TYPCALL=BALR macro call. 
DMS ABNKX Entered by a KXCHK macro to halt execution after HX 
has been entered after signaling attention. 
DMSABNGO Entered by any routine that sets up ABNPSW and 
ABNREGS in the work area beforehand. 


DMSABNXV Entered as the result of a DMSABN TYPCALL=SVC macro 
call. 
DBSABNRT Returns entry point from DEBUG. 
DMSABX Receives control when the ABNEXIT macro is executed. 
DMSABX Handles the SET or CLEAR attribute of the ABNEXIT 


macro. 
DMSABXR Handles the RESET attribute of the ABNEXIT macro. 


DMSACC ACCESS Accesses data in the ADT and related information (such 

as AFT's and chain links) in virtual storage. 
READFST Reads all file status table blocks into storage for a 

read/write disk. Reads in file management tables for 
a read - only disk. For an O/S disk, control returns 
to the caller after a successful return from DMSACM. 

DMSACM READMFD Reads the ADT, QMSK, QQMSK, and first chain link into 
virtual storage from the master file directory on 
disk. } 


DMSALP DMSALP Marks the start of the CMS nucleus code. 

DMSALU RELUFD For a specified disk, releases all tables kept in free 
storage and clears appropriate information in the 
active disk table (ADT). 

Provides an interface to VSE/VSAM Access Method 
Utility programs CIDCAMS). Provided for support of 
CMS/VSAM. 

DMSARD DMSARD Provides storage for the ASM3705 assembler auxiliary 
directory. DMSARD contains no executable code. It 
must be loaded with DMSARX and the GENDIRT command 
must then be issued to fill in the auxiliary directory 
entries. GENMOD must then be issued to create the 

| ASSEMBLE module. 


Releases storage used for tables pertaining to a given 
disk when that disk is no longer needed. 


DMSARN This is the ASM3705 command processor. It provides 
the interface between user and the 370x Assembler. 


ASMHAND This is the SYSUT2 processing routine called from 
DMSSOB and used during the assembly whenever any I/0 
activity pertains to the SYSUT2 file. 


DMSARX DMSARX Provide an interface for the ASM3705 command to the 
3705 assembler program. 
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Module 
Name 


DMSBAB 


DMSBOP 


DMSBRD 


DMSBTB 


DMSBTP 


DMSBWR 


DMSASM 
ASMPROC 


DMSAUD 


DMSAUDUP 


DMSBAB 


DMSBOP 


DMSBRD 
(RDBUF) 


DMSBTP 
DMSBTPAB 


DMSBTPLM 


DMSBTB 


DMSBWR 


Provides storage for the assembler auxiliary 
directory. DMSASD contains no executable code. It 
must be loaded with DMSASM and the GENDIRT command 
must then be issued to fill in the auxiliary directory 
entries. The GENMOD command must then be issued to 
create the assemble module. 


Processes the ASSEMBLE command. Provides the 
interface between the user and the system assembler. 
This is the SYSUT1 processing routine (called from 

DMSSOB). 


Associates logical units with a physical hardware 
device. (Interface for the ASSGN command used by 
CMS/DOS and CMS/VSAM. ) 


Reserves space on disk for writing a copy of disk and 
file management tables on disk and then updates the 
master file directory. 

Closes all CMS files, thereby updating the master file 
directory for any disks that had an output file open. 


Give control to an abnormal termination routine once 
linkage to such a routine has been established by 
STXIT AB macro. 


Opens CMS/DOS files associated with the following DTF 
(Define The File) tables: DTFCN, DTFCD, DTFPR, DTFMT, 
DTFDI, DTFCP, DTFSD. For nondisk files, the OPEN 
function is performed in its entirety by DMSBOP. For 
disk files, the SAM OPEN/CLOSE routines in CMSBAM are 
invoked. Once the files are opened and initialized, 
I/0 operations can be performed using the file. 


Reads one or more successive items from a specified 
file. DMSBRD, itself, reads items from 800-byte 
formatted disks, or calls DMSERD at the DMSERDBF entry 
point to read items from 512-, 1K-, 2K-, or 4K-byte 

formatted disks. 


Processes the BASIC command. The BASIC command 
invokes the CALL-OS BASIC language processor to 
compile and execute the specified file of BASIC source 
code. 


This is the CMS batch bootstrap routine. It loads the 
batch processor routine (DMSBTP) and user exit routine 
Cif they exist) into free storage. 


Main entry; reads from the virtual card reader each 
time CMS tries to execute a console read. 
Entry point for abnormal conditions during user job: 


Job execution ABEND Cfrom DMSABN) 
e Job limit exceeded (from DMSITE, DMSCIO, DMSPIO) 
e Disabled CMS command (from the command) 


Non-executable user job limit table referenced by 
DMSITE, DMSPIO, and DMSCIO. 


Writes one or more successive items into a specified 
disk file. DMSBWR, itself, writes to 800-byte 
formatted disks, or calls DMSERD at the DMSEWRBF entry 
point to write items to 512-, 1K-, 2K-, 4K-byte 
formatted disks. 
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Module 
Name 


DMSCAT DMSCAT Stacks a line of console input that DMSCRD reads later 
when it is called. 
DMSCATMK MAKEBUF command. 
DMSCATNB SENTRIES command. 


CATCHECK Provides an interface to the VSE/VSAM Catalog Check 
Service Aid. Provided for support of CMS/VSAM. 


DMSCIOR 
DMSCIOP 
DMSCIOSI 


Reads one card record. 
Punches one card record. 
Punch caller's buffer. 


DMSCIT DMSCIT Processes the interruptions for all CMS terminal I/0 
operations and starts the next I/0 operation upon 
completion of the current I/0 operation. 

DMSCITA Processes terminal interruptions. 
DMSCITB Starts next terminal I/0 operation. 
DMSCITDB Frees I/0 buffers from stacks. 
DMSCITDK DROPBUF command. 
DMSCLS DMSCLS Closes CMS/DOS files associated with the following DTF 


(Define The File) tables: DMTCN, DTFCD, DTFPR, DTFMT, 
DTFDI, DTFCP, and DTFSD. For nondisk files, the 

CLOSE function is performed in its entirety by CMSCLS. 
For disk files, the VSE OPEN/CLOSE routines in CMSBAM 
are invoked. 


DMSCMP COMPARE Compares the records contained in two disk files. 


DMSCPF | DMSCPF Passes a command line to CP for execution. 
DMSCPY DMSCPY Processes the COPYFILE command to copy disk files. 


Reads an input line and makes it available to the 
caller. 
Simulates VTOC functions for CMS formatted disks in 
the CMS/DOS environment. 

| DMSCWR =| DMSCHR Writes an output line to the console. 


DMSCWT DMSCWT Causes the calling program to wait until all terminal 
I/0 operations have been completed. 


| pMsDAS =| _‘DMSDAS. Simulates the VSE ASSIGN macro. 


DMSDBD DMSDBD Enables a user to dump his virtual storage from within 
an executing program. 


DMSDBG DMSDBG petal ated ai user to debug his program from the 
erminal. 
DMSDBGP Entry point for program interruptions. 
DMSDBG Entry point for all other interruptions. 
DMSDDL DMSDDL Send files in NETDATA form to a user on a local or a 


remote node. Receive and query NETDATA files in 
user's reader. 


DMSDID Returns the virtual address, blocksize, and offset of 
a RESERVEd mini-disk to the user. 


DMSDIOR Reads one or more 800-byte records (blocks) from disk, 
or reads one 200-byte record (sub~block) from disk. 
DMSDIOW Writes one or more 800-byte records (blocks) on disk, 


or writes one 200-byte record (sub~-block) on disk. 
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Module Entry 
Name Points 


DMSDLB DMSDLB Interface for the CMS/DOS DLBL command; allows the 
user to specify I/0 devices extents, and certain file 
attributes for use by a program at execution time. 
DLBL can also be used to modify or delete previously 
defined disk file descriptions. 


DMSDLK DMSDLK Interface for the CMS/DOS DOSLKED command. Link-edit 
the relocatable output of the language processors. 
Once link-edited, these core image phases are added to 
the end of the specified DOSLIB. 


DMS DMP Simulates the VSE $$BDUMP. A CP DUMP command is 
issued, directing the dump to a virtual printer. 
DMSP DP Simulates IDUMP, JDUMP, and PDUMP. For IDUMP, the 


PRINTL macro is issued. For JDUMP and PDUMP, a CP 
DUMP command is issued directing the dump to a virtual 
printer. 


Provides DOS SVC support. Interprets DOS SVC codes 
and passes control to appropriate routines for 
execution (for example, OPEN, CLOSE, FETCH, EXCP). 
Dumps a disk file to cards or loads files from card to 
disk. 

DMSDSL DMSDSL Provides capability to delete members (phases) of a 
DOSLIB library; also, to compress a DOSLIB library; 

also, to list the members (phases) of a DOSLIB 
library. 

| pmspsv =| ‘DMSDSV. Lists: the directerids of DOS erivate or system packs. | 
Arranges compound Coverstruck) characters into an 
ordered form and disregards tab characters as special 
characters. 

DMSEDF DMSEDF Provides the Editor with the proper settings (CASE, 
TAB, FORMAT, SERIAL, etc.) by filetype. Contains 
nonexecutable code for reference by DMSEDI. 

Modifies the contents of an existing file or creates a 
new file for editing. 


| DMSEDX | DMSEDX —| Performs initialization for the CMS Editor. 


DMSEIO Processes EXECIO command. 
DMSEIOI Initialization routine. 


DMSERDBF Reads one or more items from a specified 512-, 1K-, 


2K-, or 4K-byte formatted disk. 
DMSEWRBF Writes one or more items from a specified 512-, I1K-, 
2K-, or 4&K-byte formatted disk. 


Builds a message to be written at the virtual console 
by DMSCWR. 
Deletes a file or related group of files from 
read/write disks. 
DMSETR DMSETR Ruonnee? SVC 98 EXTRACT macro support. Called by 
OSs. 


DMSEXE DMSEXE Processes an EXEC 2 file. 


Determine whether to call CMS EXEC, EXEC 2 processor, 
a Product Interpreter. (¢DMSEXT, DMSEXE, or 
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Name ) 


DMSEXT DMSEXT Processes a CMS EXEC file. 


DMSFCH DMSFCH Bring a specified phase into storage from a system or 
private core image library or from a CMS DOSLIB 
library. DMSFCH 1s invoked via SVC l, 2, or 4 or via 
the FETCH command. 

DMSFET DMSFET Provides an interface for the FETCH command; also, 
provides the capability to start execution of a 
specified phase. 


DMSFLD DMSFLD Interprets OS JCL DD parameters for use by CMS. 


DMSFLE DMSFLE Processes the CLEAR and LIST functions for the FILEDEF 
command. 
DMSFNC DMSFNC Nucleus resident command name table. 
DMSFNCSV Standard SVC table.: . F 


DMSFNS DMSFNSA Closes one or more input or output disk files. 
DMSFNSE Closes a particular file without updating the 

directory or removing it from the active file table. 

DMSFNST Temporarily closes all output files for a given disk. 


DMSFOR DMSFOR Physically initializes a disk space for the CMS data 
management routines. For an existing disk, any 
information on the disk may be destroyed. The label 
may be changed and the number of cylinders allowed may 
be changed. Reads and writes one track at a time. 


DMSFRE DMSFREB Called as a result of the DMSFREE and DMSFRET macro 
calls. Allocates or releases a block of storage 
depending upon the code in NUCON location CODE203. 

DMSFREES Called as a result of the SVCFREE macro call. The 
size of the block is loaded from the PLIST and a 
DMSFREE macro is executed. Upon return, the address 
of the allocated block is stored into the PLIST. 

DMSFRETS Called as a result of the SVCFRET macro call. The 
size and address of the block to be released are 
loaded from the PLIST and a DMSFRET macro is executed. 

DMSFREEX Called as a result of a BALR to the address in the 
NUCON location AFREE. Executes the DMSFREE macro. 

DMSFRETX Called as a result of a BALR to the address in the 
NUCON location AFRET. Executes the DMSFRET macro. 

DMSFRES Called as a result of executing the DMSFRES macro. 
DMSFRES processes the following service routines: 
CKOFF, INITL, INIT2, CHECKS, UREC, and CALOC. 


DMSGIO Creates the DIAGNOSE and CCWs for an I/0 operation to 
a display terminal from a virtual machine. 


DMSGLB DMSGLB Defines the macro libraries to be searched during 
assembler processing. Defines text libraries to be 
searched by the loader for any unresolved external 
references. 


DMSGLO DMSGLO Handles GLOBALV command requests to: 1) define global 
variables for short term use in table(s) in storage, 
or long term use in CMS files; 2) retrieve and stack 
variables for use by EXECs. 


DMSGMF DMSGMF Provides support for SVC 107 GETFLD and MODFLD macros. 
Called by DMSDOS. 


| DMSGHD =| DMSGND —| Generates auxiliary system status table. 


> 
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Edits STAGE] output (STAGE2 input), builds 3705 
assembler files, link-edits text files and an EXEC 
macro file. 
DMSGTM DMSGTM Provides support for SVC 34 GETIME macro. Called by 
DMSDOS. 
DMSGVE DMSGVE Provides support for SVC 99 GETVCE macro. Called by 
DMSDOS and DMSGMF. 


DMSHDI Sets the CMS interruption handling functions to 
CHNDINT) transfer control to a given location for an I/0 device 
other than those normally handled by CMS, or clears 
previously initialized I/0 interruption handling. 
SVC number Cother than 202) or to clear such previous 
handling. 
DMSHLB DMSHLB Processes and builds output for .BX HELP format word. 
DMSHLD DMSHLD HELP facility communication module, loaded into free 
storage by DMSHLI. 
DMSHLE DMSHLE Builds messages to be written at virtual control by 
DMSHLS. 


DMSHLI DMSHLI Contains HELP facility initialization routines. 


DMSHLP DMSHLP HELP facility module for processing HELP description 
file input. 


Initializes the SVCINT SVC interruption handler to 
transfer control to a given location for a specific 


DMSHLS DMSHLS Contains HELP facility I/0 routines. 
\ SWRTPREP Determines virtual terminal characteristics and 
acquires buffer storage. 
SWRTIO Performs normal virtual terminal I/0. 


SWRTMSG Performs I/0 to virtual terminal for error messages. 
GOPEN Performs OPEN function for HELP description file. 
GREAD Routine to read HELP file input. 

GCLOSE Routine to perform file closing functions on exit. 


IDENTIFY Display or stack information about the virtual 
machine. 


Implements the IMAGEMOD command. This command is used 
to modify specific members of a 3800 named system. 
With this command, you can dynamically delete, add, 
replace, and generate members for a named system. 


| | pmsimm =| DMSIMM | Handles the IMMCMD macro and the IMMCMD command. 
Handles either user-defined synonyms or abbreviations 
or system-defined synonyms for command names. 
| DMSIND | DMSINDEX lidex: of CMS: listings. ia tha microtiche deck. 
DMSINIR Reads a nucleus into main storage. 
DMSINIW Writes a nucleus onto a DASD unit. 


DMSINM Obtains the time from the CP timer. 
CGETCLK) 


CCMSTIMER) 


| DMSINS | DMSINS Controls initialization of the CMS nucleus. 
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Module 
Name 


DMSINT DMSINT Reads CMS commands from the terminal and executes 
them. Entry is from DMSINS. 

DMSINTAB Entry from DMSABN. 
SUBSET CMS subset entry. 
DMSIOW, Places the virtual CPU in the wait state until the 
WAIT, completion of an I/0 operation on one or more devices. 
DMSIOWR, 
WAITRTN 

DMSITE DMSITE, Processes external interruptions. 


EXTINT, 
DMSITET, 


TRAP 
This module is entered when an I/0 operation causes 
the I/0 new PSW to be loaded. This module handles all 
I/O interruptions, passes control to the interruption 
processing routine, and returns control to the 


DMSITI DMSITI, 
IOINT 
interrupted program. 


DMSITP DMSITP Processes program interruptions and processes SPIE 
exits. 


DMSITS DMSITS | Avoids CP overhead due to SVC call. 

DMSITS1 Address pointed to by the CMS SVC new PSW. This point 
is entered whenever an SVC interruption occurs. 

DMSITSCR Return point to which a program called by a CMS SVC 
returns when it is finished processing. 

DMSITSNU NUCEXT handling. 

DMSITSOR Return point to which a program called by an OS SVC 
returns when it is finished processing. 

DMSITSK Called by an SVC by the DMSKEY macro. ; 

DMSITSXS Called by an SVC from the DMSEXS macro. 

DMSITSR This is the DMSITS recovery and reinitialization J 
routine, called by DMSABN. DMSABN is the ABEND 
recovery routine. 

DMSITSSB SUBCOM handling. 


| DMSIUC DMSIUC Handles the CMSIUCV and HNDIUCV macros. 
DMSLAB DMSLAB Simulates the VSE LABEL macro. 


DMSLAD DMSLAD, Finds the active disk table block whose mode matches 

ADTLKP the one supplied by the caller. 

DMSLADN, Finds the first or the next ADT block in the active 

ADTNXT disk table. 

DMSLADW Finds the read or write disk according to input 
parameters. 

DMSLADAD Modifies the file status table chain to include an 
auxiliary directory, or clears the auxiliary directory 
from the chain. 


DMSLAF DMSLAF, Finds the active file table block whose filename, 

ACTLKP ek hig and filemode match the one supplied by the 
caller. 

DMSLAFNX, Finds the next or first AFT block in the active file 

ACTNXT table. 

DMSLAFFE, Finds an empty block in the active file table or adds 

ACTFREE a new block from free storage to the active file 
table, if necessary, and places a file status entry 
Cif given) into the AFT block. 

DMSLAFFT> Removes an AFT block from the active file table and 

ACTFRET returns it to free storage if necessary. 
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DMSLBD DMSLBD Allows the user to specify tape label information that 
will be used by a program at execution time (the 
parameters are similar to those of the DOS TLBL 
statement or the tape options of the OS data 
definition statement). LABELDEF can also be used to 
modify, delete, and list previously described label 
descriptions. 

DMSLBM DMSLBM Generates a macro library, adds macros to an existing 
library, and lists the dictionary of an existing macro 
library. 

DMSLBR DMSLBR Simulates the VSE LBROPEN, LBRFIND, and LBRGET macros 
as required by the VSE ESERV utility program. 


DMSLBT DMSLBT, Creates a text library, adds text files to an existing 
TXTLIB text library, creates a disk file that lists the 
control section and entry point names ina text 
library or types, at the terminal, the control section 
and entry point names in a text library. 


DMSLCK DMSLCK SVC 110 LOCK/UNLOCK macro support. Called by DMSDOS. 


DMSLDF DMSLDF Provides support for SVCs l, 2, 4, and 65 that 
correspond to macros FETCH, FETCH, LOAD, and CDLOAD, 
respectively. Called by DMSDOS. 


’ DMSLDR DMSLDRA Begins execution of a group of programs loaded into 
real storage. Definition of all undefined programs 
is established at location zero. Entered from the 
START command or internally from DMSLDRB LDT routine 

| if START is specified. 
DMSLDRB Processes TEXT files that may contain the following 
cards: SLC, ICS, ESD, TXT, REP, RLD, END, LDT, 
LIBRARY, and ENTRY. Entered from DMSLDP when the load 


function is requested. 

DMSLDRC Does the processing required by various loader 
routines when an invalid card is detected ina text 
file 

DMSLDRD Does the processing required when a fatal I/0 error is 
detected ina text file. 


DMSLDS DMSLDS Lists information about specified data sets residing 
on an OS disk. Processes the LISTDS command. 
DMSLFS DMSLFS, Finds a specified FST entry within the FST blocks for 
TYPSRCH read-only or read/write disks. 


DMSLGT DMSLGTA Entered from DMSLDRB if not a dynamic load. Frees all 
the TXTLIB blocks on the TXTLIB chain. 


DMSLGTB Reads TXTLIB directories into a chain of free storage 
directory blocks. Entered from DMSLDRB. 


DMSLIB DMSLIB Searches TEXT libraries for undefined symbols and 
closes the libraries. 

DMSLIC DMSLIC Provides support for SVC 50 LIOCS ERROR. Called by 
DMSDOS. 

DMSLIO DMSLIO Creates the load map on disk and types it at the 
terminal. Performs disk and typewriter output for 
DMSLDR. 

DMSLKD DMSLKD Si an interface between CMS and the VS1 linkage 
editor. 


DMSLLU DMSLLU Lists the assignments of logical units. 
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DMSLOA DMSLOA Processes the LOAD and INCLUDE commands to invoke the } 
relocating loader. 

DMSLOS DMSLOS Provides load and relocate support for OS load modules 
and CMS LOADLIB modules. 


DMSLSB 


DMSLBC 
DMSLBD 


DMSLST DMSLSTA 


DMSLSBA 
DMSLSBB 


Hexadecimal to binary conversion routine. 
Adds a symbol to the string of locations waiting for 
an undefined symbol to be defined. 


Removes the undefined bit from the REFTBL entry and 
replaces the ADCON with the relocated value. 
Processes LDR options. 


Processes the LISTFILE command. Prints information 
about the specified files. 


DMSLSY DMSLSY Generates a unique character string of the form 
2000001 for private code symbols. 


DMSMCM DMSMCM 


Provides support for SVC 5 MVCOM macro. Called by 
DMSDOS. 


DMSMDP DMSMSP Types the load map associated with the specified file 
on the terminal. 


DMSMOD GENMOD 


DMSMVE 


LOADMOD 


DMSMVE 


Processes the GENMOD command to create a file that is 
a core image copy of the loaded object code. 

Processes the LOADMOD command to load a file that is 
in core image form. 


Transfers data between two specified OS ddnames, the 
ddnames may specify any devices or disk files 
supported by the CMS system. 


DMSMVG DMSMVG Handles input for the MOVEFILE command when the input J 
is a DOS FBA file. 


DMSNAM 
DMSNAMI 


DMSNCP DMSNCP 


DMSNUC DMSNUC 


NUCON 
SYSREF 
DEVTAB 
ADTSECT 
AFTSECT 
EXTSECT 
IOSECT 
PGMSECT 
SVCSECT 
DIOSECT 
FVS 
OPSECT 
CVTSECT 
DBGSECT 
TSOBLKS 


Processes the NAMEFIND command. Displays or stacks 
information contained in a "NAMES' file. 
Install NAMEFIND as a nucleus extension. 


Reads a 3705 control program module CEmulator Program 
or Network Control Program) in OS load module format 
and writes a page-format core image copy on a VM/SP 
system volume. 


Contains CSECTS for nucleus work areas and permanent 
storage. 

Nucleus constant area. 

Nucleus address table. 

Device table. 

Active disk table. 

Active file table. 

External interruption storage. 
I/0 interruption storage. 
Program Interruption storage. 
SVC interruption storage. 

Disk I/0 storage. 

File system storage. 

Parameter lists. 

Simulated OS CVT. 

Debug storage. 

TSO control blocks. 


DMSNXD DMSNXD Processes the NUCXDROP command. 
DMSNXL DMSNXL Processes the NUCXLOAD command. 
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Module 
| | Name 
C | DMSNXM | DMSNXM —s|_ Processes the NUCXMAP command. 

| DMSOME =| DMSOME Marks the end of the CMS nucleus. 


| DMSOPL DMSOPL Reads the appropriate system directory records and 
| headers and determines if the specified libraries 
contain any active members. Returns the disk address 
of the specified system library and indicates whether 
or not there are active members to be accessed on the 
| disk. 
DMSOPT DMSOPT Sets VSE options in the System Communications Region 
as specified by the OPTION command. 
DMSOR1 Relocates all DTF (Define The File) Table address 
constants to executable storage addresses. (Called by 
SSBOPENR via SVC 2.) 
Relocates all DIF (Define The File) Table address 
constants to executable storage addresses. (Called by 
DMSOR1. ) 
Relocates all DTF (Define The File) Table address 
constants to executable storage addresses. (Called 
by DMSOR2.) 
DMSOSR Allows user to invoke a program from a CMS LOADLIB or 
an OS module library. 


DMSOVR Analyzes the SVCTRACE command parameter list and loads 
the DMSOVS tracing routine. 


Provides trace information requested by the SVCTRACE 
command. 


DMSPIO 
DMSPIOCC 


Prints one line. 
Puts CCWs to select translate table (for virtual 3800) 
and to print the data, plus the data itself, in the 
caller's buffer. 

Prints the caller's buffer, issues an SIO to the 
virtual printer, and analyzes the resulting status. 


DMSPIOSI 


Places the address of a file status table entry in the 
active file table Cif necessary), and sets the read 

pointer or write pointer for that file to a given item 
number within the file. 


The module containing the supplied action routine for 


DMSPNT DMSPNT 
| DMSPOL DMSPOL 
loading a routing table for the programmable operator 
facility. 


DMSPOP DMSPOP The Programmable Operator command module. 

DMSPOQ DMSPO0Q The module containing various programmable operator 
facility internal subroutines. 

DMSPOR DMSPOR The module containing the supplied action routines for 

| the programmable operator. 
The module containing the supplied action routine for 
routing a message for the programmable operator 
facility. 
DMSPREEP Combine, link, and relocate multiple text Cobject) 

files into a single text file. 


DMSPRT DMSPRT Prints CMS files. 


c 
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Module 
Name 
Copies procedures from the VSE system procedura 
library to a specified output device. 
| DMSPUN =| _DMSPUN | Punches CMS files to the virtual card punch. 
DMS@RS a | Processes the QUERY DISK and SEARCH subcommands from 
DMSQRY. 


DMSQRT DMS@Q@RT Processes the following QUERY subcommands: ABBREV, 
AUTOREAD, BLIP, CMSTYPE, EXECTRAC, IMESCAPE, IMPCP, 
IMPEX, LDRTBLS, PROTECT, RDYMSG, RELPAGE, SYSNAMES, 
and CMSLEVEL. 


| DMSQRU =| DMS@RU Processes the QUERY FILEDEF and LABELDEF subcommands. 


DMSQRV Processes the QUERY INPUT, OUTPUT, and SYNONYM 
subcommands. 
Processes the QUERY LIBRARY, MACLIB, TXTLIB, DOSLIB, 
and LOADLIB subcommands. 

DMSQRX Processes the QUERY DOSPART, OPTION, DOSLNCNT, UPSI, 
DLBL, and DOS subcommands. 


DMS QRY DMSQRYI Loads QUERY as a nucleus extension. 
DMSQRY Initializes QUERY work area, if necessary. Processes 
the QUERY command by passing control to one of the 
following: 


1. Another QUERY module: for a CMS subcommand with 
the correct syntax. 

- CP: for a subcommand, other than a CMS subcommand. 
Caller: for a syntax error. 


DMS QRZ Non-executable constants used by DMSQRY to initialize 
the work area for the CMS QUERY command. 


| DMSRDC READCARD Reads cards and assigns the indicated filename. 


DMSRDR DMSRDR Processes the RDR command. Stacks and displays the 


characteristics of the first file in the virtual 
DMSREX DMSREX 


reader. 
Reads the EXEC file; calls DMSRIN. 
DMSRIN 
DMSRXE 


Parses input data, controls most execution decisions, 
and passes clauses to DMSRXE for execution. 
Executes individual clauses. 

DMSRCN Performs character conversion, console I/0, general 
services, and all arithmetic. 

DMSREV Evaluates expressions. 

DMSRFEN 

DMSRVA 

DMSRTC 

DMSRSF 


Performs built-in functions. 


Accesses and maintains System Product Interpreter 
variables. 

Formats and displays trace information. 

Performs additional functions similar to the built-in 
functions. 


Provides an interface for the CMS Editor RENUM 
subcommand, which renumbers files with filetypes of 
VSBASIC and FREEFORT. 


Processes the RENAME command. Changes the fileid of 
the specified file. 
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Module 
Name 


DMSROS Accesses OS disks. 
ROSACC | 

DMSROS+4 Verifies the existence of OS disks. 
ROSSTT 


DMSROS+8 Reads OS disks. 

ROSRPS 

DMSROSt+12 Finds a member in an OS PDS. 

ROSFIND 

DMSROS+16 Performs NOTE, POINT, and BSP functions. 
ROSNTPTB 


Se unen support for SVC 85 RELPAG macro. Called by 
DMSDO 

DMSRRV Provides the capability to copy (to an output device) 
modules residing on DOS system or private relocatable 
libraries. 

Distributes all the blocks of a mini-disk between the 
directory file, allocation map file, and user's file. 
DMSRSV sets up pointer blocks for each of these files. 

DMSSAB DMSSAB Processes OS ABEND macros. 

DMSSBD DMSSBD Accesses data set records directly by item number. It 
converts record identifications given by OS BDAM 
macros into item numbers and uses these item numbers 
to access records. 

Processes 0S BSAM READ and WRITE macros. 

DMSSBSRT Entry for error return from call to DMSSBD. 

DMSSCN Transforms the input line from a series of arguments to 
a series parameter strings. 

DMSSCR DMSSCR Loads display buffers and issues a macro resulting in a 
CP DIAGNOSE to write to the display terminal. 

DMSSCT DMSSCTNP Processes OS POINT, NOTE, CHECK, and FIND Ctype C) 


macros. 
DMSSCTCK Processes OS CHECK macro. 


DMSSCTCE Handles QSAM I/0 errors for DMSSQ@S and PDS and keys 
errors for DMSSOP. 
| DMSSCTTP SETs and CLEARS the CMS tape end-of-volume exits. 


Calls device I/O routines to do I/O and sets up ECB 
and JOB return codes. 


DMSSET DMSSET Processes the SET command. 


DMSSFF DMSSFF Provides overlay support for 0S load modules. 

DMSSIG DMSSIG The anchor table for the SSTAT and YSTAT. Also marks 
the end of the CMS nucleus code. 

DMSSLN DMSSLN Handles OS contents management requests issued under 
CMS (LINK, LOAD, XCTL, DELETE, ATTACH, EXIT). 
Processes OS FREEMAIN and GETMAIN macros and CMS calls 
DMSSMNSB and DMSSMNST. 


| pMssop =| DMssop_—si| Processes OS OPEN and CLOSE macros. 
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Processes the SETPRT command. This command sets up a J 
virtual 3800 printer spool file for a CMS user. With 

the SETPRT command, a user can select the character 

arrangement tables, copy modification modules, FCB, 

and forms overlay frame for printing files with a 

virtual 3800. 


Analyzes record formats and sets up the buffers for 
GET, PUT, and PUTX requests. 

DMSSRT DMSSRT Arranges records within a file in descending 
sequential order. 
Provides capability to copy books from a system or 
private source statement library to a specified output 
device. 


Sets storage protect key for a specified saved system. 


DMSSTG Processes CMS calls to DMSSTGST and DMSSTGSB C(STRINIT) 
and storage service routines. 
DMSSTGOS Processes the EXECOS command. 
DMSSTGSB STRINIT. 
DMSSTGST 
DMSSTGCL OS exit reset routine. 
DMSSTGSV Service routine to change nucleus variables. 
DMSSTGAT Initializes storage and sets up an anchor table. 
DMSSTT DMSSTT Locates the file status table entry for a given file 
and, if found, provides the caller with the address of 
the entry. 
DMSSTX DMSSTX Provides support for SVCs 16, 17, 37, and 95 that 


correspond to macros STXIT PC, EXIT PC, STXIT AB, and 
EXIT AB> respectively. Called by DMSDOS. 


| DMSSUB | DMSSUB SVC 105 SUBSID macro support. Called by DMSDOS. 
DMSSVL DMSSVL SVC 75 SECTVAL macro support. Called by DMSDOS. 
| DMSSVN | DMSSVN Procasses the 0S WAIT snd POST macros. 


DMSSVT DMSSVT Processes OS macros: XDAP, TIME, SPIE, RESTORE, BLDL, 
FIND, STOW, DEVTYPE, TRKBAL, WTO, WTOR, EXTRACT, 
IDENTIFY, CHAP, TTIMER, STIMER, DEQ, SNAP, ENQ, 
FREEDBUF, STAE, DETACH, CHKPT, RDJFCB, SYNAD, 
BACKSPACE, and STAX. f : 

Builds a keys file when a data file using keys is 
opened and saves the keys in the data file when it is 
closed. 

DMSSYN SYNONYM Processes the SYNONYM command. Sets up user-defined 
command names and abbreviations for CMS commands. 

DMSTIO DMSTIO Reads or writes a tape record or controls tape 
positioning. 

DMSTLB DMSTLB Processes IBM standard tape labels for OS simulation, 
CMS/D0OS, CMS commands, and TAPESL macro. Also 
provides linkage to nonstandard user label routines 
for OS simulation and CMS commands. 


DMSTMA DMSTMA Reads an IEHMOVE unloaded PDS from tape and places it 
in a CMS MACLIB. 
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Module Entry 
( Name Points 


DMSTPD DMSTPD Reads a tape consisting of card image members of a PDS 
and creates CMS disk files for each member of the data 
set. The PDS option allows reading unblocked tapes 
produced by the OS IEBPTPCH utility or blocked tapes 
produced by the OS IEHMOVE utility. The UPDATE option 
provides the ™./ ADD" function to blocked or unblocked 
tapes produced by the IEBUPDTE utility. 


DMSTPE DMSTPE Processes the TAPE command to perform certain tape 
functions, such as: dump a CMS file, load a CMS file, 
set tape mode, display or write VOL1 labels, scan, 
skip, rewind, run, FSF, FSR, BSF, BSR, ERG, and WIM. 


DMSTPF DMSTPF Tapeload function. 


DMSTPG DMSTPG Dump functions of TAPE command. 
DMST@Q . DMSTRQ 
DMSTQQX 


Allocates a 200-byte first chain link (FCL) toa 
calling program. 

Makes a 200-byte disk area no longer needed by one 
program available for allocation to another program. 


DMSTRK DMSTRKA 


DMSSTRKX 


Allocates an 800-byte disk area to a calling program. 
Makes an 800-byte disk area that jis no longer needed 
by one program available for allocation to another. 


DMSTYP TYPE Processes the TYPE command. Types all or a specified 


part of a given file on the user's console. 


Processes the UPDATE command. Updates source files 
according to specifications in update files. Multiple 
updates can be made, according to specifications in 


control files that designate the update files. 


C 


DMSUTL DMSUTL List, copy, or compress LOADLIBs. 
First table of Access Method Services nonshared 
Cnonreentrant) modules. 
DMSVAS Contains a table of Access Method Services shared 
(reentrant) modules. 
DMSVAX DMSVAX Second table of Access Method Services nonshared 
Cnonreentrant) modules. 


Contains table of simulated VSE phases located in 
CMSBAM DCSS. 


| Loads the CMS/VSAM saved system and pass control to 


the CMS/VSAM interface routine, DMSVIP. 
DMSVIP 


DMSVIS DMSVIS Provide support for SVC 61 GETVIS macro and for SVC 62 
FREEVIS macro. Called by DMSDOS and DMSLDF. 


DMSVLT DMSVLT Simulates VSE SSBOSVLT transient. Provides return 
linkage from SAM OPEN/CLOSE routines to CMS/DOS 
routines. 

Resets any flags or fields set by VSAM processing; 
purges the VSAM discontiguous shared segment. 
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Module 

Name 

DMSVVN DMSVVN Contains table of VSE/VSAM nonshared C(Cnonreentrant) J 
modules. 


DMSVVS DMSVVS Contains table of VSE/VSAM shared Creentrant) modules. 
| DMSWTE DMSWTE Processes the WAITECB function. 


DMSXBG DMSXBG Allocates and initializes storage for the XEDIT work 
area. Processes the XEDIT command. 


DMSXCG CDELETE Processes the subcommands Centry points) listed. 
CHANGE 
COMPRESS 
COPY 
COUNT 
COVERLAY 
DELETE 
DUPLICAT 
EXPAND 
LOWERCAS 
MERGE 
MOVE 
OVERLAY 
UPPERCAS \ 
RECOVER ) 
SHIFT 


DMSXCM aoe Processes the subcommands Centry points) listed. 
CM 


CP 
DMSXCN DMSXCN Arranges compound characters into canonical form; 
disregards tab characters as special characters. 


DMSXCP DMSXCP Simulates the VSE EXCP function (VSE SVC 0) in the 
CMS/DOS environment. EXCP CExecute Channel Program) 
requests initiation of an I/0 operation to a specific 
logical unit. 


DMSXCT CMSG Processes the CMSG subcommand. 
CURSOR Processes tha CURSOR subcommand. 
DMSXCTPN Processes the SET POINT subcommand. 
DMSXCTTE Processes the SET TERMINAL subcommand. 
DMSXCTSC Processes the SET SCREEN subcommand. 

Processes the EMSG subcommand. 
Processes the FILE/PFILE subcommand. 
Processes the LPREFIX subcommand. 
Processes the MSG subcommand. 
PRESERVE Processes the PRESERVE subcommand. 
PURGE Processes the PURGE subcommand. 
READ Processes the READ subcommand. 
REFRESH Redisplays the screen. 
RENUM Processes the RENUM subcommand. 


REPEAT Processes the REPEAT subcommand. 
RESET Processes the RESET subcommand. 
RESTORE Processes the RESTORE subcommand. 
SAVE Processes the SAVE/PSAVE subcommand. 
TYPE Processes the TYPE subcommand. 


DMSXDC DMSXDCOD Scans input from the terminal for a subcommand or 
macro; operands are decoded and placed in buffers. 
Executes the MACRO and COMMAND subcommands. Performs 
synonym substitution. 
DMSXDCSY Processes the SET SYNONYM subcommand. 
DMSXDCST Executes multiple synonyms. 


DMSXDS DMSXDSRD Reads a data set (SAM) from an OS formatted disk. ) 
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| DMSXED XEDIT Processes the XEDIT subcommand; brings a file into the 
ring of files in storage. 
DMSXEDRT Removes an edited file from storage (QUIT). 


DMSXER DMSXERMG Displays an error message in the standard CMS format: 
DMSxxxnnne message text.... 


DMSXFC DMSXFCNX Moves the line pointer to the next line. 
DMSXFCUP Moves the line pointer to the previous line. 
DMSXFCPL Moves the line pointer to line number “"n", 
DMSXFCML Moves the current line UP] or NEXTl. 
DMSXFCLA Locates a line by its address. 
DMSXFCCD Moves the column pointer to the right. 
DMSXFCCG Moves the column pointer to the left. 
DMSXFCLM Locates a specified string (FIND) in the current line. 
DMSXFCDP Inserts the column pointer as "_" in a buffer. 
DMSXFCIN Inserts a new line in the file. 
DMSXFCRL Replaces a line in the file with a new one. 
DMSXFCSU Deletes one line from the file. 
DMSXFCRC Performs string substitution in the current line. 
DMSXFCRM Performs an overlay function on the current line. 
DMSXFCSP Handles special characters, ex., tab, backspace. 
DMSXFCDC Displays SET VERIFY or SET TABS columns. 
DMSXFCLR Defines the logical record length. 
DMSXFCTR Defines the truncation column. 
DMSXFCHT Defines the top of range. 
DMSXFCBT Defines the end of range. 
DMSXFCGA Defines the zone left column. 
DMSXFCDR Defines the zone right column. 
DMSXFCPC Sets the column pointer in column "n". 
DMSXFCCC Sets the cursor to column "c" in the file. 
DMSXFCCL Sets the cursor to line "1" in the file. 
DMSXFCTB Sets up the tabulation columns. 

DMSXFCPI Checks if a line has to be spilled. 


DMSXFDFI Writes the file on disk. 

DMSXFDSR Serializes the file in storage. 

DMSXFDTG Performs target processing. 

DMSXFDLE Locates an extended string (a string with arbitrary 
characters). 

DMSXFDLN Locates a named line. 


DMSXFL DMSXFLST Determines if a file is in the XEDIT ring, and if so, 

returns its characteristics. 

DMSXFLRD Transfers one Cor more) records from XEDIT storage to 
the calling program. : 

DMSXFLWR Transfers one Cor more) records to XEDIT storage from 
the calling program. 

DMSXFLPT Moves the current line pointer to the record specified 
by the calling program. 


DMSXGT Process the GET subcommand. 
DMSXHL HELP Invokes the CMS HELP facility. 


DMSXINTF 
DMSXINLA 


DMSXINLD 
DMSXINLX 
DMSXINOP 


Initializes a file descriptor block. 

ag the profile macro if an error occurs during 
OAD. 

Processes the LOAD subcommand. 

Processes an explicit LOAD, from the profile macro. 

Handles XEDIT command options. 


Performs I/70 at the terminal. 
Reads at the terminal. 
Writes at the terminal. 
Displays message pending in the message line. 


DMSXIORD 
DMSXIOWR 
DMSXIOMG 
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Executes XEDIT macros (files written in EXEC 2 J 
language or REXX language). 

Executes subcommand from XEDIT macros. 

States existence of a macro and reads it. 

Releases a macro from free storage. 


DMSXML 


UP 
Arranges records within a file in a descending or 
ascending sequential order (SORT macro). 


DMSXMAOP 


DMSXMAEX 
DMSXMARD 
DMSXMARS 


CFIRST 
CLAST 
CLOCATE 
LEFT 
RIGHT 
DMSXMCVR 


INPUT 
ADD 
REPLACE 
CREPLACE 
CINSERT 


BACKWARD 


CFIRST subcommand. 
CLAST subcommand. 
CLOCATE subcommand. 
LEFT subcommand. 

RIGHT subcommand. 

SET VERIFY subcommand. 


Processes 
Processes 
Processes 
Processes 
Processes 
Processes 


Processes subcommands Centry points) listed. 


Processes subcommands Centry points) listed. 


> 


| DMSXPO POWERINP Allows easy input mode for script users. 


DMSXPT 


PUT 
PUTD 
DMSXPTER 


DMSXPXDC 
DMSXPXEX 
DMSXPXPN 
DMSXPXRS 


QUERY 

TRANSFER 
DMSXQRPT 
DMSX@RCL 
DMSXQRPY 
DMSX@RPK 
DMSXQRPF 
DMSXQRPN 
DMSXQRTK 


Processes the PUT subcommand. 
Processes the PUTD subcommand. 
Erases the temporary file used by GET/PUTCD). 


Decodes prefix subcommands and macros. 
Executes prefix subcommands and macros. 
Sets a prefix in the pending list. 
Resets an entry in the pending list 


Contains the QUERY/TRANSFER subcommands. 
Stacks variable from the editor. 

Handles QUERY POINT. 

Handles QUERY COLOR. 

Handles QUERY PREFIX SYNONYM. 

Handles QUERY PF/PA key. 

Displays PF/PA/Enter Key definition. 
Handles QUERY PENDING. 

Gets the next token in the operand. 


| DMSXRE || DMSXRE | Processes the RENUM subcommand. 
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DMSXST 


DMSXSCDP 
DMSXSCFL 


DMSXSCIM 
DMSXSCPR 
DMSXSCCN 
DMSXSCCP 


DMSXSCIO 
DMSXSCFR 


DMSXSCRV 
DMSXSCCS 


DMSXSDLS 
DMSXSDSC 
DMSXSDPH 
DMSXSDLN 
DMSXSDML 
DMSXSDMS 
DMSXSDSR 
EXTSCRBF 
MOVTOSCR 


DMSXSFRS 
DMSXSFCT 
DMSXSFMG 
DMSXSFCR 
DMSXSFSL 
DMSXSFDM 


SOS 

DMSXSSXY 
DMSXSSTB 
DMSXSSTF 


DMSXSTLG 
DMSXSTNB 
DMSXSTCP 
DMSXSTEX 
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Dispatches a logical screen. 

Computes to which logical screen belongs a field on 
the physical screen. 

Builds and displays all the logical screens. 

Checks if the cursor is in a protected area. 

Scans the buffer read from the screen. 

Prints an image of the physical screen (COPYKEY 


function). 


Handles I/0 on a 3270. 

Transforms a buffer read by READ BUFFER to a buffer 
equivalent to READ MODIFIED FIELD. 

Displays a line in the 3270 command line. 

Sets the cursor on the screen. 


Builds a logical screen block. 

Builds a logical screen. 

Builds the physical screen. 

Builds a line to be displayed. 

Moves a line from screen buffer in the file. 
Builds the scale line. 

Scans a line for CTLCHAR. 

Extends the input/output buffer. 

Moves a line to the output buffer. 


DMSXSE rail Handles the SET RANGE subcommand. 
Handles the SET subcommand. 


Processes the 
Processes the 
Processes the 
Processes the 
Processes the 
Processes the 


SET 
SET 
SET 
SET 
SET 
SET 


subcommand. 

RESERVED subcommand. 
CTLCHAR subcommand.. 
MSGLINE subcommand. 
COLOR subcommand. 
SELECT subcommand. 


Decodes a line number (M # n). 


Processes the S0S subcommand. 

Computes the EBCDIC address of the cursor. 
Tabs backward in the file on the command line. 
Tabs forward in the file on the command line. 


Gets a free line in storage. 

Computes the number of free lines available. 
Combines free lines in one free block. 
Dynamically extends the storage for the files. 


Section 3: CMS Directory 207 


Licensed Material-~-Property of IBM 


Module 
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supervisor. 


DMSXSU DMSXSUVR 
DMSXSUPE 
QUIT 
DMSXSUFL 
DMSXSUNP 
DMSXSU 
DMSXSUIG 
DMSXSUTY 
DMSXSUEF 
DMSXSUTF 
DMSXSUTE 
DMSXSUTP 
DMSXSUNC 
DMSXSUNF 
DMSXSUPR 
DMSXSULG 
DMSXSUEX 
DMSXSUCK 
DMSXSUTS 
DMSXSUCN 
DMSXSUCC 
DMSXSUCH 
DMSXSUHC 
DMSXSULK 
DMSXSURV 
DMSXSUPK 
DMSXSUQM 
PQUIT 


DMSXTE 
DMSXTERG 
DMSXTEEN 
DMSXTEVR 
DMSXTECL 
DMSXTESC 
DMSXTEPS 


DMSXTERS 
DMSXTEPK 
DMSXTEHK 
DMSXTEPT 
DMSXTESY 
DMSXTEPD 
DMSXTECC 
DMSXTEFP 


DMSXTEGS 
DMSXTESH 
DMSTEEX 


DMSXTR 
EXTRACT 
DMSXTRSE 
DMSXUP DMSXUPCK 


DMSXUPAT 
DMSXUPCT 
DMSXUPBL 
DMSXUPDL 
DMSXUPR2 


Editing 


Executes the profile macro. 
Executes the QUIT subcommand. 


Flushes 


subcommand execution if no more save area. 


No operation Cused when a macro ends). 
Redisplays the last input in the input area. 
Maintains file integrity on multiple windows. 
Types the current Line. 

Types “EOF™. 

Types "TOF". 

Types "TOF" or "EOF". 

Checks displacement to a target line. 

Types "NO CHANGE". 

Types "NOT FOUND". 

Checks for prefix subcommand or macro waiting. 
Computes line length. 

Executes a subcommand. 

Checks if fname ftype fmode are valid. 
Computes autosave identification. 

Performs EBCDIC-binary conversion. 

Performs binary-EBCDIC conversion. 

Performs EBCDIC-hexadecimal conversion. 
Performs hexadecimal-EBCDIC conversion. 
Checks coherency between file and logical screen. 
Redisplays the last entry in the input area. 
Executes PFKEY/PA2/PA3/Enter Key. 

Executes ? command. 


Removes 


one file from the ring of files in storage 


(protected QUIT). 


DMSXTB DMSXTBHC Address of hash code table. 
DMSXTBRQ Address of subcommand table. 


Contains the second half of the EXTRACT subcommand. 


Assigns 
Assigns 
Assigns 
Assigns 
Assigns 
Assigns 


ring settings to EXEC 2/REXX variables. J 
enter settings to EXEC 2/REXX variables. 

VERIFY settings to EXEC 2/REXX variables. 

COLOR settings to EXEC 2/REXX variables. 

SCREEN settings to EXEC 2/REXX variables. 

PREFIX SYNONYM settings to EXEC 2/REXX 


variables. 


Assigns 
Assigns 
Handles 
Assigns 
Assigns 
Assigns 
Assigns 


RESERVED settings to EXEC 2/REXX varaibles. 
PF/PA Key settings to EXEC 2/REXX variables. 
setting PF/PA Key values for a specified key. 
POINT settings to EXEC 2/REXX variables. 
SYNONYM settings to EXEC 2/REXX variables. 
PENDING settings to EXEC 2/REXX variables. 
CTLCHAR settings to EXEC 2/REXX variables. 


Parses input up to the end of input, or delimiter, or 


a blank 


Gets storage from buffer DMSFREED in DMSXTR. 


Sets up 


SHVBLOCK. 


Performs an EXECCOMM. 


DMSXTF DMSXTF Filetype descriptor table. 


Contains the EXTRACT subcommand. 


Assigns 
Sets up 
routine 


editor settings to EXEC 2/REXX variables. 
SHVBLOCK for variable not requiring a special 
to compute variable value. 


Checks for proper serialization. 


Applies 
Handles 


one update file to the source file. 
CNTRL and AUX files for multi~level update. 


Builds the update file Csubcommands SAVE or FILE). 


Handles 


deleted lines in the source file. 


Builds error messages. F 
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Module 

Name 

DMSXWS DMSXWSQR Checks the terminal characteristics and allocates the 
screen buffer. 

DMSZAP Processes the ZAP command. Provides a facility to 
maintain es LOADLIB members as written by the CMS 
command LKE 

DMSZAT DMSZAT Defines 8K-bytes of transient area. 
DMSZIT DMSZIT Defines the end of the CMS nucleus in user storage. 


DMSZNR | DMSZNR Defines the end of NUCON (DMSNUC). 
DMSZUS DMSZUS Defines the start of the user area. 
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SECTION §:; CMS DIAGNOSTIC AIDS 


C 


This section contains the following information: 


A list of devices supported by a CMS Virtual Machine 
® DMSFREX Error Codes 


e Abend Codes 
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SUPPORTED DEVICES 


J 


Figure 32 indicates those devices that are supported by a CMS 
machine. 


Virtual Virtual Symbolic 

IBM Device Type Address® Name (default) Device Use 
3210, 3215, 1052, CON1 System console 
3066, 3270 


2314, 2319, 3310, CMS System disk Cread-only) 
3330, 3340, 3350, Primary disk Cuser files) 
3370, 3375, 3380 Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 
Minidisk Cuser files) 


2540, 2501, 3505 RDR1 Vitus cosder 
2540, 3525 | oo PCH1 Vi tual. punch 


1403, 1443, 3203, PRNI Line printer 
3211, 3262, 3800, 
a — 


3289-4 
Figure 32. Devices Supported by a CMS Virtual Machine 


2401, 2402, 2403, 
2415, 2420, 3410, 
3411, 3420, 3430, 
8809 


The device addresses shown are those that are preassembled 
into the CMS resident device table. These need only be 
modified and a new device table made resident to change the 
addresses. 


The virtual address of the system console may be any valid 
multiplexer address. 


8 191 is the default user~accessed A~disk unless it is 


dynamically changed by an ACCESS at CMS initial program 
load CIPL). 


> 
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ERROR CODES FROM DMSFRES, DMSFREE ND _ DMSFRET 


A nonzero return code upon return from DMSFRES, DMSFREE, or 
DMSFRET indicates that the request could not be satisfied. 
Register 15 contains this return code, indicating which error 
has occurred. The following codes apply to the DMSFRES, 
DMSFREE, and DMSFRET macros. 


Code 
] 


Error 


(DMSFREE) Insufficient storage space is available to 

satisfy the request for free storage. In the case of a 
variable request, even the minimum request could not be 
satisfied. 


CDMSFREE or DMSFRET) User storage pointers destroyed. 


CDMSFREE, DMSFRET, or DMSFRES) Nucleus storage 
pointers destroyed. 


(DMSFREE) An invalid size was requested. This error 
exit is taken if the requested size is not greater than 
zero. In the case of variable requests, this error 
exit is taken if the minimum request is greater than 
the maximum request. (However, the latter error is not 
detected if DMSFREE is able to satisfy the maximum 
request. ) 


(DMSFRET ) An invalid size was passed to the DMSFRET 
macro. This error exit is taken if the specified 
length is not positive. 


CDMSFRET) The block of storage that is being released 
Was never allocated by DMSFREE. Such an error is 
detected if one of the following errors is found: 


e The block does not lie entirely inside either the 
free storage area in low storage or the user 
program area between FREELOWE and FREEUPPR. 

e The block crosses a page boundary that separates a 
page allocated for user-type storage from a page 
allocated for nucleus-type storage. 

° The block overlaps another block already on the 
free storage chain. 


CDMSFRET) The address given for the block being 
released is not on a doubleword boundary. 


CDMSFRES) An invalid request code was passed to the 
DMSFRES routine. Since all request codes are generated 
by the DMSFRES macro, this error code should never 
appear. 


CDMSFREE, DMSFRET> or DMSFRES) An internal error 
occurred in the free storage management routine. 
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ABEND RECOVERY 
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Modules Used: DMSABN 
ration of the Abend Routine, DMSABN 


When the abend recovery routine, DMSABN, is entered, it checks 
for any ABEND exit routines set by the ABNEXIT macro. If a list 
of exit routines exists, the current exit routine (that is, the 
last one set) gains control. 


After receiving control, the following occurs: 


1. The exit routine receives control with the nucleus protect 
key and disabled interrupts. 


2. Information about the abend is available to the exit routine 
in the DMSABW CSECT in DMSNUC. The address of this area is 
passed to the exit routine via register l. In addition to 
the information currently available in DMSABW, a fullword 
specified on the ABNEXIT macro for the exit's own purposes 
is also available. 


3. If a program check occurs in the exit CABNEXIT RESET has not 
been issued), DMSABN gives control to the previous exit in 
the list. If there is not an exit to trigger, normal CMS 
abend recovery occurs. 


4. Abend exits cannot be set or cleared from within an exit 
routine. You can issue the ABNEXIT macro with the RESET 
option only from within an exit. 


After completion of the ABEND exit routines, the exit can do one 
of the following: 


1. Returns to DMSABN via a branch on register 14. DMSABN calls 
the previous exit in the list or proceeds with normal CMS 
abend processing. 


2. Returns elsewhere by loading the PSW at the time of abend 
Cavailable in DMSABW) or a modified version of the PSW. 
Prior to loading the PSW, the ABNEXIT RESET form of the 
macro should be issued. 


When DMSABN continues with normal abend processing, it may type 
out the abend message, followed by the line "CMS", that you may 
type in your next command. 


At this point, there are two options available to you. 


First, you may type the DEBUG command. In this case, DMSABN 
passes control to DMSDBG, to make the facilities of DEBUG 
available to you. DEBUG's PSW and registers are as they were at 
the time that the abend recovery routine was invoked. From 
DEBUG, you may alter the PSW or registers, and either type GO to 
continue processing or type RETURN to return to DMSABN so that 
abend recovery can continue. 


The second option available is to type in any other command. If 
this is done, DMSABN performs its abend recovery function and 

ie ir control to DMSINT to execute the command that has been 
yped in. 


The abend recovery function performs the following functions, in 
sequence: 
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1. 
2. 
3. 


23. 


Clears the console input buffer and program stack. 
Terminates all VMCF activity. 


Reinitializes the SVC handler, DMSITS, and frees all stacked 
save areas. 


Clears the auxiliary directories, if any. Invokes "FINIS * 
x ¥," to close all files, and to update the master file 
directory. 

Zeroes out EXECFLAG and frees at EXEC global storage. 
Zeroes out the maclib directory pointers. 

Frees the CMS work area, if the CMS subset was active. 


Issues the STAE, SPIE, TTIMER, and STAX macros to cancel any 
outstanding OS exit routines. Frees any TXTLIB, MACLIB, or 
LINK tables. 


Calls with a purge plist, all nucleus extensions that have 
the "SERVICE" attribute defined. 


Drops all nucleus extensions that do not have the "SYSTEM" 
attribute. Also drops any nucleus extensions that are in 
type user storage. 


Frees all SCBLOCKs associated with SUBCOM. 

Clears all immediate commands that are not nucleus 
extensions with the "SYSTEM" attribute. Returns all 
associated free storage. 

Frees all storage of type user. 

Zeroes out all interrupt handler pointers in IQOSECT. 
Turns the SVCTRACE command off. - 


Closes the virtual punch and printer. Closes the virtual 
reader with the HOLD option. 


Zeroes out all FCB, DOSCB, and LABSECT pointers. 


Reinitializes the VSE lock table used by CMS/DOS and 
CMS/VSAM. 


Zeroes out all OS loader blocks, and frees the FETCH work 
area. 


Disables the CMS IUCV environment, and all IUCVIDBKs and 
frees CMS IUCV system storage. 


Clears all ABNEXIT set and frees storage. 

Computes the amount of system free storage that should be 
allocated and compares this amount with the amount of free 
storage actually allocated. Types a message to the user if 
the two amounts are unequal. 


Issues a STRINIT if all storage is accounted for. 


After abend recovery has been completed, control passes to 
DMSINT at entry point DMSINTAB to process the new command that 
was typed in. 


UNRECOVERABLE TERMINATION -- THE HALT OPTION OF DNSERR 


There are certain times, such as when the SVC handler's pointers 
are modified, that the system can neither continue processing 
nor try to recover. In these cases, DMSERR with the option 
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Figure 33 (Part 1 of 4). 
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HALT=YES is specified to cause a message to be typed out, after 
which a disabled wait state PSW is loaded unless the NUCON field 


AUSERRST has been loaded. 


The valid address contained in AUSERRST is assumed to be the 


address of an error recovery routine and wi 
The initialization routines of an application 


branched to. 


ll be directly 


running under CMS must set this address to point to a module 
that might, for example, request a dump and then issue an IPL 


command. 


IPL CMS PARM AUTOCR 


If the IPL command is 


and the PROFILE EXEC on virtual disk 191 invokes 


reinitialization, 
automatic recovery. 


the application has the capability of 
This capability is valuable for CMS service 


virtual machines that run permanently disconnected and are 


required to stay operational. 


In CP mode, the programmer can examine the PSW, whose address 
field contains the address of the instruction following the call 


to the DMSERR macro. 


The programmer can also examine all the 


registers, which sere as they were when the DMSERR macro was 


invoked. 


Figure 33 lists the CMS ABEND codes and describes the cause of 
the abend and the action required. 


Abend Module 
Code Name Cause of Abend 


The problem program 
encountered an input/output 
error processing an OS macro. 
Either the associated DCB did 
not have a SYNAD routine 
specified or the I/0 error was 
encountered processing an 05S 
CLOSE macro. 


The problem program 
encountered an I/0 error while 
processing a VSAM action macro 
under VSE for which there is 
An internal 


no OS equivalent. 
error occurred in a VSE/VSAM 
routine. 


An error occurred in VSE/VSAM 
processing while running an 
OS/VSAM program, for which 
there ts no equivalent OS/VSAM 
error code. 


CMS Abend Codes 


Message DMSSCT1205S 
indicates the possible 
cause of the error. 
Examine the error message 
and take the action 
indicated. 


Refer to VSE/VSAM 
Messages and Codes, to 
determine the cause of 
the VSAM error. 


Refer to the VSE/VSAM 
documentation for the 
error and return codes 
indicated in the CMS 
error message preceding 
the ABEND. 


ABEND Codes 217 


Licensed Material--Property of IBM 


Abend Module 
Code Name Cause of Abend ) 


0Cx DMSITP The specified hardware Type DEBUG to examine the 
exception occurred at a PSW and registers at the 
specified location. "x" is time of the exception. 

the type of exception: 
x Type 

IMPRECISE 

OPERATION 

PRIVILEGED OPERATION 

EXECUTE 

PROTECTION 

ADDRESSING 

SPECIFICATION 

DECIMAL DATA 

FIXED-POINT OVERFLOW 

FIXED-POINT DIVIDE 

DECIMAL OVERFLOW 

DECIMAL DIVIDE 

EXPONENT OVERFLOW 

EXPONENT UNDERFLOW 

SIGNIFICANCE 

FLOATING-POINT DIVIDE 


DMSITS Insufficient free storage is If the abend was caused 

available to allocate a save by an error in the 

area for an SVC call. application program, 
correct it; if not, use 
the CP DEFINE command to 
increase the size of 
virtual storage and then 
restart CMS. 


DMSITS An invalid halfword code is Enter DEBUG and type GO. J 
associated with SVC 203. Execution continues. 


MMOS DS WOOANAUBHANEH SO 


DMSITS The CMS nesting level of 20 None. Abend recovery 
has been exceeded. takes place when the next 
command is entered. 

OF3 DMSITS CMS SVC (202 or 203) Enter DEBUG and type GO. 
instruction was executed and Control returns to the 
provision was made for an point to which a normal 
error return from the routine return would have been 
processing the SVC. made. 

OF4 DMSITS The DMSKEY key stack Enter DEBUG and type GO. 
overflowed. Execution continues and 

the DMSKEY macro is 
ignored. 

OF5 DMSITS The DMSKEY key stack Enter DEBUG and type GO. 
overflowed. Execution continues and 

the DMSKEY macro is 
ignored. 

OF6 DMSITS The DMSKEY key stack was not Enter DEBUG and type GO. 
empty when control returned Control returns from the 
from a command or function. command or function as if 

the key stack had been 
empty. 

OF? DMSFRE Occurs when TYPCALL=SVC Cthe When a system abend 
default) is specified in the occurs, use DEBUG to 
DMSFREE or DMSFRET macro. attempt recovery. 


Figure 33 (Part 2 of 4). CMS Abend Codes J 
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Module 
Name 


DMSFRE 


Abend 
Code 


OF8 


Cc 


Occurs when TYPCALL=BALR is 
specified in the DMSFREE or 
DMSFRET macro devices. 


The wait count specified in an 
OS WAIT macro was larger than 


the number of ECBs specified. 


The OS interface to VSE/VSAM 
is unable to continue 
execution of the problem 
program. 


104 DMSVIB 


on. 


15A DMSSLN Severe error during load 
(phase not found) after an OS 
LINK, LOAD, XCTL, or ATTACH. 


The compiler switch is on. 


DMSXSU Occurs when XEDIT cannot 
allocate a save area to a 
called routine. 
174% DMSVIB The OS interface to VSE/VSAM 
1s unable to continue 
execution of the problem 


program. 


177 DMSVIB 


DMSVIP 


The OS interface to VSE/VSAM 
1s unable to continue 
execution of the problem 
program. 


240 DMSSVT No work area was provided in 
the parameter list for an OS 


RDJFCB macro. 


= 
oS 
Qo 


DMSSVT 
of the OS XDAP macro was 
issued by the problem program. 


DMSTLB A block count error was 
detected when reading a SL 
tape. User replied 'cancel' 
to message 425R or the user's 
program contained a block 
count error routine that 
returned a code of 0 under OS 
simulation. 


Figure 33 (Part 3 of 4). 


CMS Abend Codes 


C 


DMSSLN Error during LOADMOD after an 
OS LINK, LOAD, XCTL, or 
ATTACH. The compiler switch is 


An invalid or unsupported form 
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jonse of avert | neti 


When a system abend 
occurs, use DEBUG to 
attempt recovery. 


Examine the program for 
excessive wait count 
specification. 


See the additional error 
message accompanying the 
abend message, correct 
the error, and reexecute 
the program. 


See the last LOADMOD 
CDMSMOD) error message 
for error description. 

In the case of an I/0 
error, recreate the 
module. If the module is 
missing, create it. 


See last LOAD error 
message (DMSLIO) for the 
error description. In 

the case of an I/O error, 
recreate the text deck or 
TXTLIB. If either is 

missing, create it. 


None. Abend recovery 
takes place when the next 
command 1s entered. 


See the additional error 
message accompanying the 
abend message, correct 

the error, and reexecute 
the program. 


See the additional error 
message accompanying the 
abend message, correct 

the error, and reexecute 
the program. 


Check RDJFCB 
specification. 


Examine program for 
unsupported XDAP macro or 
for SVC 0. 


Find out what caused the 
block count error. Then 
reload CMS and rerun the 
job. 
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Abend Module 
Code Name Cause of Abend 


An OS GETMAIN macro (SVC 4) 

was issued specifying the LC 
or LU operand. 
are not supported by CMS. 


An OS FREEMAIN macro (SVC 5) 
was issued specifying the L 
operand. This operand is not 
supported by CMS. 


An OS GETMAIN macro (804 - SVC 


4, 80A - SVC 10) was issued 
that requested either zero 
bytes of storage or more 
storage than was available. 


An OS FREEMAIN macro (905 - 
SVC 5, 90A - SVC 10) was 
issued specifying an area to 
be released whose address was 
not on a doubleword boundary. 


An OS FREEMAIN macro (CA05 - 
SVC 5, AOA - SVC 10) was 
issued specifying an area to 
be released that overlaps an 
existing free area. 


Figure 33 (Part 4 of 4). CMS Abend Codes 


These operands 


Change the program so 
that it specifies 
allocation of only one 
area at a time. 


Change the program so 
that it specifies the 
release of only one area 
at a time. 


Check the program for a 
valid GETMAIN request. If 
more storage was 
requested than was 
avatlable, increase the 
size of the virtual 
machine and retry. If 
you run out of storage 
while trying to acquire a 
large GETMAIN area and if 
the size of your virtual 
machine is above the 
start of the CMS nucleus, 
you should IPL a CMS 
system generated at a 
higher virtual address 
than the one you are 
using. If the saved 
system CMSL is avatlable, 
then IPL it; if not, then 
contact your system 
Support personnel. 


Check the program for a 
valid FREEMAIN request; 
the address may have been 
incorrectly specified or 
modified. 


Check the program for a 
valid FREEMAIN request; 
the address and/or length 
may have been incorrectly 
specified or modified. 
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C 


The following is a list and brief description of the CMS macros 
applicable to VM/SP. 


Asterisk (*%) indicates that the macro is reserved for IBM use. 


CMS Macro 
¥ADT 
*ADTGEN 
*XADTSECT 
XAFT 
XAFTSECT 


Generates a CSECT or DSECT for an active disk table. 

Generates an active disk table (ADT) for a disk; used by ADTSECT. 
Generates all the ADTs for CMS. 

Generates a DSECT for an active file table. 


Generates all the AFTs for CMS. 


BATLIMIT Table of CPU, punch, and printer limits for user jobs running 
under CMS batch. 


BBOX DSECT of boundary box; contains beginning and ending addresses of 
background communication region. 


DSECT of background communication region. 
BGTCB 
X¥CMSAVE 
xCMSCB 


~~ XCMSCVT 


X¥CMSLEVEL 


Task Control Block. 
Equivalent to SVCSAVE macro. 


Generates a list of simulated OS control blocks. 


Generates the communication vector table as supported by CMS. 


Defines the value of ‘release number’ of the feature or program 
product returned by QUERY CMSLEVEL. Refer to the CMSLEVEL macro 


for more information. 


COMPSWT Sets the compiler switch on or off. Refer to VM/SP CMS Command 
and Macro Reference. 


Sets the origin for CSECT. 
XDBGSECT Generates a CSECT or DSECT for DEBUG environment variables. 


DESTYP Used by the XEDIT module DMSXIN to determine filetype default 
settings. The DESTYP block is defined in DMSXTF. 


Xx DEVGEN Generates a device table for a given device; used by the DEVTAB 
macro. 


*DEVSECT 
*XDEVTAB 


DSECT for a device table. 
Generates the device tables for the CMS nucleus. 
Issues a specified CP Diagnose instruction. 


Disk Information Blocks. 


X¥DIOSECT Generates a CSECT or DSECT for all I/0 information. 


Generates the calling sequence for the display terminal interface. 
Refer to VM/SP System Programmer's Guide. 


Appendix A. CMS Macro Library 221 


DMSABN ABEND the virtual machine. Refer to VM/SP System Programmer's 
Guide. 
*DMSCCB DSECT describes field of DOS command control block (CCB). Refer 


to VM/SP Data Areas and Control Block Logi Volume 2 (CMS). 


*¥DMSABW Allocates a work area for DMSABN. 
Reserved for IBM use. 


Sets up parameter list to type out a CMS error message; Refer to 
the LINEDIT macro. 


*DMSERT DMSERR work area DSECT. 


Execute an instruction without nucleus protection. Refer to VM/SP 


System Logic and Problem Determination Guide--Volume 2. 
DMSFREE Gets free storage. Refer to VM/SP System Programmer's Guide. 


*DMSFRES Calls system free storage service routines. 


DMSFRET Releases free storage. Refer to VM/SP System Programmer's Guide, 


*¥DMSFREX Calls system free storage service routines. 


XDMSFRT Generates a DSECT for free storage management work area. 
¥DMSFRX Submacro called by DMSFRET. 


DMSFST Sets up a file status table for a given file. Refer to VM/SP 
System Programmer's Guide. 
DMSKEY Sets nucleus protection on or off. Refer to VM/SP System Logic 


and Problem Determination Guide--Volume 2. 


*DMSLN Called by DMSERR, LINEDIT macros. 
*¥DMSLNC Called by DMSERR, LINEDIT macros. 
*DMSLND Called by DMSERR, LINEDIT macros. 


*DMSLNP Called by DMSERR, LINEDIT macros. 
*DMSLNU Called by DMSERR, LINEDIT macros. 
*DMSLNY Called by DMSERR, LINEDIT macros. 


X¥DMSLNZ Called by DMSERR, LINEDIT macros. 


Passes a fileid in quotes into separate filename, filetype, 
filemode, used by FSCB, and FSPOINT. 


¥DMSTMS Used by RDTAPE, WRTAPE, and TAPECTL. 
DOSAVE 


DOSCB 


DSECT, describes fields in the logical transient area (LTA). 


DOS simulation control block used for simulation of the CMS file 
control block (FCB). 


Creates CMS/DOS control blocks for DMSNUC. 
DTFSD DSECT. 


DOSCON 
DTFSD 


DT FX DTF extension DSECT. 


i 


C 


C 


CMS Macro 


*XEPLIST 
XEQUATES 
¥EXCP 
¥EXTSECT 


FSCB 


*¥FSCBD 
FSCLOSE 

XFSENTR 
FSERASE 
FSOPEN 

¥FSPOINT 
FSREAD 


FSSTATE 


XFSTB 
XFSTD 
FSWRITE 


XFVS 

¥GETADT 

*¥GETFST 
HNDEXT 


HNDINT 


HNDSVC 
IJJHCPL 
IJJHDLST 
IJJHMFT1 


¥IOSECT 
XKEYSECT 
¥KXCHK 
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Frees storage control blocks initialized by DMSEDX for CMS edit 
modules. 


DSECT to map extended plist passed in register 0. 
Generates CMS equates for symbolic names. 

Issues an SVC 0. 

Defines storage for the timer interrupt. 


Generates a file control block (FCB) DSECT. 


Sets up a file system control block. Refer to VM/SP CMS Command 
and Macro Reference. 


DSECT that describes fields in CMS PLIST for related commands. 
Closes a file. Refer to VM/SP_ CMS Command and Macro Reference. 
Used by CMS file system routines at entry. 

Erases a file. Refer to VM/SP CMS Command and Macro Reference. 
Opens a file. Refer to VM/SP CMS Command and Macro Reference. 
Executes the CMS POINT function. 


Reads a record from a file. Refer to VM/SP CMS Command and Macro 


Reference. 


Checks for an existing file. Refer to VM/SP CMS Command and Macro 
Reference. 


Generates a file status table (file directory) block. 
Entry to the file status table (file directory) block. 


Writes a record into a disk file. Refer to VM/SP CMS Command and 
Macro Reference. 


Defines storage for file system variables. 


Gets a specified active disk table. 


Gets a specified file status table. 


Handles external and timer interrupts. Refer to VM/SP_ CMS Command 
and Macro Reference. 


Handles interrupt on devices. Refer to VM/SP CMS Command and 
Macro Reference. 


Handles SVCs. Refer to VM/SP_ CMS Command and Macro Reference. 
Common VTOC handler input PLIST. 

Common VTOC handler descriptor list DSECT. 

Format 1 VTOC label DSECT. 

Contains PLISTs needed to access CMS I/0 routines. 

Defines miscellaneous I/0 variables. 

Contains variables necessary for storage key handling. 


Checks to see if HX has been entered by the user. 
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LABREC DLBL/EXTENT record. 
Loads double multiple (for floating point registers). 
*LDRST CMS Loader work area. 
LINEDIT Types a line to the terminal. Refer to VM/SP CMS Command and 
Macro Reference. 
LOCKTAB LOCK/UNLOCK resource table. 
LPLDCT LABEL macro PLIST. 
LSCREEN Used by XEDIT modules to describe the layout of a logical screen 
on the physical screen. LSCREEN is built by module DMSXSD. 
*NUCON Generates a DSECT CMS nucleus constant area. 
OocTS OPEN/CLOSE transient SVA PLIST. 
XOVSECT DMSOVS work area. 
XOSFST Defines an 0S file status table for OS ACCESS. 
*¥*PDSSECT DSECT used for processing MACLIB files. 
¥PGMSECT Defines work area for DMSITP. 
PIBTAB DSECT, program information block. 
PIB2TAB DSECT, program information block extension. 
PRINTL Prints a line on the printer. Refer to VM/SP CMS Command and 
Macro Reference. 
PRSCB Used by the XEDIT subcommands PRESERVE and RESTORE. It is built 
by module DMSXCT. 
PUNCHC Punches a card. Refer to VM/SP CMS Command and Macro Reference. 
RDCARD Reads a card from the reader. Refer to VM/SP CMS Command and 
Macro Reference. 
RDTAPE Reads a record from tape. Refer to VM/SP_ CMS Command and Macro 
Reference. 
RDTERM Reads a record from the terminal. Refer to VM/SP_ CMS Command and 
Macro Reference. 
RECSAVE Used by XEDIT modules to describe the address list for nested 
macro calls. It is built by DMSXMA. 


Generates symbolic register equates. Refer to VM/SP_ CMS Command 
and Macro Reference. 


XRELPAGES Sets the release pages flag. 
Used by XEDIT modules to describe all XEDIT subcommands and their 
operands and syntax. The REQDES block is defined in DMSXTB. 
ee | Used by XEDIT modules to save register contents during subroutine 
calls. 


¥STDM Storage for multiple floating-point registers. 


STRINIT Initializes storage. Refer to VM/SP_ CMS Command and Macro 


Reference. 


RL 


c 


cK 


J 


¥SUBSECT 
*¥SVCENT 


X¥SVCSECT 
SYNSUB 


SYSCOM 
¥SYSLOAD 


XSYSNAMES 
TAPECTL 
*TSOBLKS 


*TSOGET 


XUSERSECT 
WAITD 


WAITT 


WRTAPE 


WRTERM 


ZDESC 
ZFONC 


ZMACST 
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Used by XEDIT modules to describe the synonyms defined for XEDIT 


subcommands. A SYNSUB block is built dynamically by DMSXDC each 
time a synonym is defined. 


DSECT of system communication region. 


Puts in a specified register the address of a specified routine in 
NUCON. 


Saves system names table loaded via CMS routines. 
Positions a tape Refer to VM/SP CMS Command and Macro Reference. 
Contains CPPL, UPT, PSCB, and the ECT for TSO service routines. 


cers the address of the TSO command processor parameter list 
CPPL). 


Generates assembler USING and DROP instructions, as needed 


Waits until the next interrupt occurs for the specified device. 
Refer to VM/SP_CMS Command and Macro Reference. 


Waits until all pending I/O to the terminal has completed. Refer 
to VM/SP CMS Command and Macro Reference. 


Writes a record to tape. Refer to VM/SP_CMS Command and Macro 


Reference. 


Writes a record to the terminal. Refer to VM/SP_CMS Command and 
Macro Reference. 


NR ER Acre LET ESTER RT SE SEES 


Used by XEDIT modules to describe file characteristics. 


Used by XEDIT modules as a common work area. It is built by 
DMSXBG only once in an editing session. 


Used by XEDIT modules to describe an XEDIT macro in storage. A 


ZMACST block is built dynamically by DMSXMA each time a macro is 
invoked. 


Used by XEDIT modules when a file is being packed or unpacked. It 
is built by DMSXIN or DMSXFD. 
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CMS, in this release, contains a DOS macro library with the 
following significant entries. A more complete list may be 
obtained by invoking the DOSMACRO EXEC; this EXEC produces a 
list of all the macros in the DOS library. 


Generates the DOS/VS command control block. 


Returns address of background partitions communication region; 
expands to SVC 33. 


Normal processing termination; expands to SVC 0. 
OPENR Activates a data file; simulated by DMSOR1L, DMSOR2, DMSOR3. 


STXIT Provides/terminates supervisor linkage to user's program 
check routines; simulated by DMSDOS. 


IKQACB DSECT for VSAM ACB Caccess method control block). 


IKQEXLST DSECT for VSAM EXLST control block (contains addresses 
of user exit routines. 


IKQRPL DSECT for VSAM RPL Crequest parameter list control block). 
ABTAB DSECT of abnormal termination option table. 

FICL DSECT, CMS/DOS first in class table. 

NICL DSECT, CMS/DOS number in class table. 


PUBOWNER DSECT, physical unit block ownership table. 
ANCHTAB DSECT, DOS/VS anchor table. 


FCHTAB DOS/VS fetch table containing fetch/load parameter list. 
MAPPUB DSECT defines fields of CMS/DOS physical unit block CPUB). 
PUBTAB DSECT same usage as MAPPUB. 

EXCPW DSECT, work area for DMSXCP routine. 

LUBTAB DSECT for CMS/DOS logical unit block. 
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SIJBLKMD 
SIJBLBSL 
SIJGXCP 

SIJGXDI 

SI JGXSDF 
SIJGXSDU 
SIJGXSDV 
SIJGXSDW 
SIJBLKMD 
SIJGXSFI 


SIJGXSRI 
SIJGXSSR 
SIJGXSVI 
SIJJGTOP 


SIJJHCVH 
DMSLBR 
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The modules listed below (by phase) make up the CMSBAM segment. 


The phases and modules Cexcept DMSLBR) retain their VSE 
identifiers. 


IJBLKMD 
IJBLBSL 
I JGXCP 
IJGXDI 
IJGXSDF 
IJGXSDU 
IJGXSDV 
IJGXSDW 
IJBLKMD 
IJGXSFI 
IJGXSRI 
IJGXSSR 
IJGXSVI 
IJJGDACX 
IJJGDAO1 
IJJGDART 
IJJGMSOO 
IJJGSDCI 
IJJGSDI2 
IJJGSDMF 
IJJGSD04 
IJJGSDUL 
TJJGSDXT 
IJJHCCVO 


DMSLBR 


IJJGDAI1 
IJJGDAO02 
IJJGDAVC 
IJJGMS10 
IJJGSDCI 
IJJGSDI3 
IJJGSDMN 
TJJGSDO5 
IJJGSDVH 
IJJGVDO0 


IJJHCVHO 


IJJGDAI2 
IJJGDA03 
IJJGMFBA 
IJJGMTOP 
IJJGSDCW 
IJJGSDI4 
IJJGSDMO 
IJJGSD06 
IJJGSDW1 
ITJJGVD10 


IJJHOPNO 


IJJGDAMO 
IJJGDA04 
IJJGMIOI 
IJJGSDBH 
IJJGSDFP 
IJJGSDI5 
IJJGSDNV 
IJJGSDO7 
IJJGSDW2 
TJJGVMO0 


IJJHRDSO 
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IJJGDAMS 
IJJGDAO5 
IJJGMLLM 
IJJGSDBS 
IJJGSDGC 
IJJGSDLP 
TJJGSDO1 
TJJGSDRL 
IJJGSDWS 
IJJGVM10 


IJJHSRNO 


IJJGDAMX 
IJJGDARL 
IJ JGMMBF 
IJJGSDCD 
IJJGSDII1 
IJJGSDMC 
IJJGSD02 
IJJGSDSF 
IJJGSDW4 


IJJHWDSO 
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abend 
See abnormal termination Cabend) 
ABEND exit 
contents of register 1 55 
module 1990 
ABEND macro 24 
abnormal termination Cabend) 
CMS 
codes 213 
recovery 215 
ACCESS command, accessing OS data 
sets 31 
access methods 
BDAM 28, 129 
BPAM 28, 129 
BSAM/QSAM 28, 129 
for non-CMS environments')3 129 
0S 28, 129 
VSAM 129 
accessing 
a virtual disk 91, 104 
the file system 91, 104 
active disk and file storage 
management 91, 100 
Active Disk Table 
See ADT CActive Disk Table) 
Active File Table 
See AFT CActive File Table) 
ADT CActive Disk Table) 
used in disk management 91, 100 
AFT CActive File Table) 
used in file management 91, 100 
allocated 
free storage, types of 115 
releasing storage allocated by 
DMSFREE 122 
releasing storage allocated by 
GETMAIN 2 
allocating storage 120 
allocation 
of a free storage 116, 
12 
of user free storage 115, 120 
selective directory update 100 
allocation map, organization 100 
AMSERV function, execution of 130 
ASA control characters) 108 
ATTACH macro 26 
AUSERRST, HALT option 216 
pl IPL command processing 46, 


description of 179 
modules used in 182 
BDAM 
CMS support of 28, 129 
restrictions on 


Licensed Material--Property of IBM 


BLDL macro 25 
block formats (CMS) 98 

BP AM 

CMS support of 28, 129 

BSAM/QSAM, CMS support of 28, 129 
BSAM, using the WRITE macro with a 
3800 printer 30 

BSP macro 27 
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called routine 

register contents, when 

started 62 

start-up table 62 
caller, returning to 63 
carriage control characters, 
CMS 108 
CATCHECK command 

module 192 
chain header block 

FLCLB in 119 


118 
SKEY in 
TCODE in 119 
chain links 86 
CHAP macro 26 
CHECK macro 27 
CHECK processing, OS VSAM 136 
CHKPT macro 27 
CLOSE/TCLOSE macros) 25 
CLOSE, OS VSAM, simulation of 135 
CMS (Conversational Monitor System) 
ABEND codes 215, 217 
accessing the file system 91 
batch 
description of 179 
modules used in 182 
called routine table 62 
CMS nucleus first part 19 
command language 3 
command processing 51, 60 
command, handling 49 
console management 53 
devices supported 19 
DEVTAB (Device Table) 19 
diagnostic aids 211 
directory 189 
disk organization 85, 88, 98 
disk storage management 91, 100 
DMSFREE macro 
description 116 
free storage management 116 
located in CMS storage 13 
service routines 122 
DMSFRES macro 122 
DMSFRET macro 121 
DMSITS module 
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user and transient areas 62 
DMSNUC (nucleus constant area) 
located in CMS storage 13 
structure of 19 
aan storage management 91, 


error codes 
DMSFREE 213 
DMSFRES 213 
DMSFRET 213 
file 
executing 51 
processing 51 
file status table block 86, 934 
file status tables 8&5, 92 
file system 
accessing 91 
description of 3 
managing 85 
routines that access the file 
system 104 
512-, 1K-, 2K-, 4K-byte 
records 4, 100 
800-byte records 4%, 6 
files 
512-, lk-, 2k-, 4k-byte 
records 932 
800-byte record 85 
first command processing 49 
free storage management 
DMSFREE 116 
GETMAIN 115 
functional information 13 
handling of PSW keys 124 
I/0 control flow 106 
I/0 operations 105 
initialization for OS SVC 
handling 
interactive console 
environment 51 
interface with display 
terminals 19 
interrupt handling 9, 113 
introduction 3 
IPL command processing 46 
loader 6 
loader tables 14 
loading from a card reader 45 
maintaining interactive 
session 
master file directory 88, 938 
miscellaneous functions 179 
module entry point 
directory 190 
nucleus 14 
OS and VSE VSAM 
functions supported 35 
hardware devices 
supported 36 
overview of functional areas 38 
printer carriage control 108 
printing a file 108 
processing commands entered 
during 51 
program 
development facilities 7 
organization 
punching a card 107 
read disk I/O 110 
reading a card 106 
record formats) 86 
register usage 13 
restrictions on, as a saved 
system 127 


returning to the calling 
routine 
routines that access the file 
system 104 ) 
simulation 
of 05S 141 
of VSE environment 157 
storage 
constant initialization 45 
maps 16 
structure of 13 
SVC handling 54 
system functions 39 
system save area 
modification 64 
transient area 14, 62 
user 
area 19 
program area 14 
USERSECT 19 
virtual devices used in 212 
virtual machine 
initialization 45 
VSE support 35 
VSE VSAM and OS 
functions supported by 
CMS 35 
hardware devices 
supported 36 
write disk I/O 1190 


CMS commands 


ACCESS 31 
file system manipulation 85 
FILEDEF 31 
poet via DMSINS, execution 
0 
process of, entered during 
CMS 52 J 
CMS macro library 221 


CMS/DOS 


CLOSE functions 161, 162 
compatible with VSE releases via 
CMSBAM DCSS 163 
DOSLKED command 165 
environment termination command 
DMSBAB 178 
DMSDMP 178 
DMSITP 178 
execution related control 
commands 164 
FETCH command 164 
initialization 158 
initialization for 0S VSAM 
processing 134% 
OPEN functions 161, 162 
service commands 


DMSDSL 178 
DMSDSV 178 
DMSPRV 178 
DMSRRV 178 
DMSSRV 178 
ESERV 178 


support modules 229 
SVC functions 
AB EXIT SVC 95 176 
AB STIXIT SVC 37 172 
CANCEL SVC 6 169 
CDLOAD SVC 65 174 
COMRG SVC 33 172 
CONTROL SVC 8 169 . 
EOJ SVC 14 170 
EXCP SVC 0 168 a 
EXTRACT SVC 98 176 
FETCH SVC 1 168 
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FETCH SVC 2 168 
FREEVIS SVC 62 174 
GETIME SVC 34 172 
GETVCE SVC 99 176 
GETVIS SVC 61 173 
JOB CTL. 170 
LBRET SVC 9 170 
LIOCS DIAG svc 50 173 
LOAD SVC 4 169 
MVCOM SVC 5 169 
PC EXIT SVC 17 171 
PC STXIT SVC 16 171 
POST SVC 40 172 
RELEASE SVC 64 174 
RELPAGE SVC 85 175 
RUNMODE SVC 66 174 
SECTVAL SVC 75 175 
simulation of 166 
$vC 26 171 
SYSFIL SVC 103 176 
TRANS/RETURN SVC 11 170 
USE SVC 63 174 
WAIT SVC 7 169 
SVC functions not 
supported 166~178 
SVC functions treated as 
NOOPsS 166-178 
SVC handling 132 
upgrade to VSE, through support 
modules in CMSBAM 229 
CMS/DOS macro library 229 
CMS/VSAM error return 
processing 136 
CMSAMS-CMSVSAM DCSSs, storage 
relationships with DMSAMS 131 
CMSBAM DCSS, contents of 163 
CMSBAM segment, modules that 
comprise this DCSS 229 
CMSCB, defined 143 
CMSCVT, defined 143 
CMSDOS-CMSVSAM-user program storage 
relationships 132 
CMSVSAM-CMSDOS-user program storage 
relationships 2 
command 
handling, CMS 51, 52 
language, CMS 3 
processing 
SET DOS ON 49 
commands 
See CMS commands 
completion processing 
DOS VSAM programs'7 136 
OS VSAM programs'7 136 
console 
management, CMS 53 
control block, manipulation macros, 
simulation of, VSAM 134 
control card routine 
ENTRY card 76 
LIBRARY card 77 
control flow for I/0 
processing 105 
conventions 
linkage 54 
SVCs 54 
Conversational Monitor System 
See CMS (Conversational Monitor 
System) 
creating program names dynamically, 
for use via SVC 202 65 
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data base, loader 78 
data set control block (DSCB) 28 
eect 


accessing 31 
defining 31 
reading 31 
DCB macro 27 
deallocation map 98 
DELETE macro 24 
DEQ macro 26 
DETACH macro 27 
devices, CMS supported 19 
DEVTAB (Device Table) 19 
DEVTYPE macro 25 
diagnostic aids, CMS 211 
directory, CMS 189 
disk 
I/0, CMS 110 
label, organization 98 
organization in CMS 85 
disk and file storage 
management 91, 100 
disk space, read/write, 
allocation 90 
disk storage management 
CMS 99 
QMSK used in 90 
QQMSK used in 90 
DISKID function 
module 192 
display terminals, CMS 
interface 19 
DISPSW macro 20 
DMSABN module 
used in CMS batch 
processing 182 
DMSACC module 
accessing a virtual disk 91 
0S access method module 152 
DMSACF module 
OS access method module 152 
DMSACM module 
0S access method module 152 
DMSALU module 
0S access method module 153 
DMSAMS module 
DMSAMS-CMSAMS-CMSVSAM storage 
relationships 131 
operation of 131 
DMSARE module 
0S access method module 153 
DMSASN module 
invoking the ASSGN command 159 
DMSBOP module 
simulates VSE OPEN 161 
VSAM processing 132 
DMSBTB module 
batch processing, bootstrap 
module 179 
general operation of 179 
DMSBTP module 
batch processing 180 
general operation of 180 
DMSCIO module 
used in CMS batch 
processing 182 
DMSCLS module 
processes CLOSE requests 162 
VSAM processing 133 
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DMSCPF module DMSINT module 953 
maintaining an interactive DMSIOW module 11 
console environment 51 DMSITE module 11 : 
used in CMS batch used in CMS batch ; 
processing 182 processing 182 ; 
DMSCRD module DMSITI module 10 
maintaining an interactive DMSITP module 11, 178 
console environment 51 DMSITS module 9, 54 
used in CMS batch DMSKEY macro 
processing 182 format of 125 
DMSDLB module DMSLDR module 
invoking the CMS/DOS DLBL PRSERCH routine 77 
command 160 REFADR routine 77 
DMSDLK module used in CMS batch 
simulating the VSE linkage processing 182 
editor function 165 DMSLDS module 
DMSDOS module LISTDS command 151 
description of 132 0S access method module 153 
DMSDOS VSAM processing 133 DMSLFS module 
DMSDSK module 0S access method module 154 
used in CMS batch DMSLKD module 
processing 182 LKED command 152 
DMSDSL module DMSLLU module 
processes CMS/DOS service request a list of CMS/DOS 
commands 178 physical units) 160 
DMSDSV module DMSMVE module 
processes CMS/DOS service MOVEFILE command 151 
commands) 178 0S access method module 154 
DMSERR module used in CMS batch 
AUSERRST NUCON field 216 processing 182 
HALT option 216 DMSNUC module 
used in CMS batch located in CMS storage 13 
processing 182 structure of 19 
DMSEXS module DMSOPT module 
format of 125 setting compiler options 159 
DMSFCH module 165 DMSOSR module 
DMSFET module 165 OSRUN command 151 
DMSFLD module DMSPIO module 
FILEDEF command 151 builds printer CCW chain 108 ‘ 
0S access method module 153 carriage control characters used 
used in CMS batch by 108 
processing 182 performing channel testing 108 
DMSFRE module used in CMS batch 
method of operation 120 processing 182 
used in free storage DMSPRV module 
management 13 processes CMS/DOS service 
DMSFRE service routine 122 commands 178 
DMSFREE macro DMSQRS module 
allocating nucleus free 0S access method module 157 
storage 120 DMSQRY module 
allocating user free displaying CMS environment 
storage 120 options 49 
error codes 128, 213 QUERY command 152 
format of 116 DMSRDC module 
free storage allocation 116 used in CMS batch 
free storage pointers) 116 processing 182 
operands 116 DMSROS module 
storage management 116 common routines'9 157 
DMSFRES macro OS access method module 154 
error codes 128, 213 DMSRRV module 
format of 122 processes CMS/DOS service 
operands 122 commands 178 
DMSFRET macro DMSSCT module 
error codes 128, 213 0S access method module 155 
format of 121 DMSSEB module 
operands 121 OS access method module 156 
releasing storage 121 DMSSET module 
DMSINI module initializing CMS/DOS operating 
used in CMS batch environment 8 
processing 182 used in CMS batch 
DMSINS module processing 182 
executing commands 51 DMSSOP module 
used in CMS batch 0S access method module 156 
processing 182 DMSSRV module 
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processes CMS/DOS service 
commands) 178 
DMSSTT module 
0S access method module 157 
STATE command 152 
DMSSVT module 
0S access method module 156 
DMSVIP module 
interface for OS VSAM requests 
and CMS/DOS and VSE/VSAM 
routines 133 
DMSXCP module 
handles VSAM requests 132 
DOS 
CLOSE functions 161 
initialization 
assign logical and physical 
units 159 
associate a DTF table 
filename with a logical 
unit 160 
for OS VSAM processing 134 
list assignments of CMS/DOS 
logical units 160 
resetting CMS/DOS environment 
options 159 
resetting compiler 
options 159 
setting CMS/DOS environment 
options 159 
setting compiler options 159 
OPEN functions 16l 
VSAM 
function supported by CMS 35 
hardware devices supported by 
CMS 36 
DOS VSAM 
completion processing 136 
execution of, for a VSE 
user 132 
DOS-OS-VSAM-user program storage 
relationships 132 
DOSCB 160 
creation of 130 
DSCB 28, 129 
DTF table 
closing files associated 
with 162 
opening files associated 
with 161 
DTF tables, disk files in FB-512 
devices 161 


dump 
DMSDBD 192 
DMSDMP 178, 193 
svc 13 145 


SVC 51 26, 147 
when debugging 13 
dynamic linkage, via SUBCOM 65 
dynamic storage management 
active disks 91, 100 
active files 931, 100 
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editor, VM/SP System Product 
Editor 5 
END card routine 75 
end~of-command exit, QSAM 
contents of register 1 55 
module 201 
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TEOVEXIT macro 137 
ENQ macro 26 
ENTRY control card 76 
entry point directory, CMS 190 
environments 
access method support for 
non-CMS 129 
ERET error routine processing 136 
error codes 
from DMSFREE 128, 213 
from DMSFRES 128, 213 
from DMSFRET 128, 213 
error return, CMS/VSAM, processing 
of 136 
error routine, ERET, 
processing 136 
ESD card codes 79 
ESD type 0 card routine 69 
ESD type 1 card routine 70 
ESD type 10 routine 72 
ESD type 2 card routine 71 
ESD type ¢ card routine 72 
ESD type 5 card routine 72 
ESD type 6 card routine 72 
ESERV 
processes CMS/DOS service 
commands) 178 
ESIDTB CESD ID table) entry 78 
EXEC 2 
logic flow for modules 
processing EXEC 2 
functions 184 
processing 184 
EXECOS command 
module 202 
executing 
CMS files 51 
text files 67 
EXIT macro 23 
exit routine 
QSAM tape end-of-volume 137 
user, processing of 136 
external interrupt 
BLIP character 11 
HNDEXT macro 11 
in CMS 11 
timer 11 
EXTRACT macro 26 
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FB-512 device, CMS block format 98 
FCB (file control block) 13 
FEOV macro 25 
file 
arrangement of fixed-length 
records, in CMS 
arrangement of variable-length 
records, in CMS 88% 
management 3 
file control block 
See FCB (file control block) 
file directory 
Physical organization 88% 
selective directory update 100 
file status table 
Sea FST Cfile status table) 
file status table block 
format 86 
file system 
CMS, management 85 
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manipulation commands 83 high-storage nucleus chain 118 
512-, lk-, 2k-, 4k-byte high-storage user chain 118 
records 92 
800-byte record 85 
FILEDEF command ) 
AUXPROC option 33 [=] 
defining OS data sets 31 
flow 151 
format of 31 I/O 
files, 0S format, support of 28 disk, CMS 105, 110 
FIND macro 25 interrupt, in CMS 10 
first chain link format 86 macros, OS VSAM, simulation 
first command processing, CMS 49 of 135 
format I/O control flow, CMS 106 
DMSEXS macro 125 I/O operations, CMS 105 
DMSFRES macro 122 ICS card routine 69 
DMSKEY macro 125 IDENTIFY macro 26 
first chain link, in CMS 87 (MAGEMOD command, used to modify a 
nth chain link, in CMS 87 3800 named system 47 
system save area 64 immediate commmands 
user save area 64 contents of register 1 55 
free chain element format 119 module 195 
free storage management initialization 
allocation of CMS virtual machine 45 
nucleus 120 CMS/DOS, for OS VSAM 
user 120 processing 134 
DMSFREE 116 DMSINS module 45 
GETMAIN 115 for a named system 47 
pointers 116, 117 for a saved system 47 
free storage table for OS SVC handling, CMS 47 
FREETAB 118 storage contents, CMS 45 
NUCCODE 118 system tables 45 
SYSCODE 118 VSE 158 
TRNCODE 118 input restrictions, loader 8:0 
USERCODE 118 input/output 
FREEDBUF macro 26 See I70 
FREEMAIN macro 24 interactive console environment, 
FREEPOOL macro 24 CMS 51 
FREETAB free storage table 118 interrupt handling 
FST (file status table) CMS 
CMS 85, 92 input/output interrupts 10 
format 86, 94 SVC interrupts 
functional area, overview, CMS 38 terminal interrupts 10 
DMSITS 9 
external interrupts ll 
machine check interrupts) ll 
[| program interrupts ll 


reader/punch/printer 
interrupts Ill 


GENCB processing 135 user-controlled device 
GET macro 29 interrupts Ill 
GETMAIN interrupts, processing 113 
free element chain 119 introduction, CMS 
free storage INTSVC 54 
allocation 115 IPL 
management pointers 116 by device name 15 
GETMAIN/FREEMAIN macros 24 by system name 15 
releasing storage allocated by IPL command processing 
GETMAIN 122 AUTOCR 46, 217 
Simulation 16 CMS 46 
GETMAIN macro 23 IUCV CInter-User Communication 
GETPOOL macro 24 Vehicle) 
module 196 
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HALT option 216 
AUSERRST NUCON field 217 
handling 


OS files 
on CMS disks 21 
on OS and DOS disks 2l 
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key 
read PSW 126 
real storage 126 
virtual PSW 126 
virtual storage 126 
keys, storage protection 124 


LIBRARY control card 77 
LINK macro 24 
linkage conventions 
SVCs 54 
LISTDS command flow 151 
LKED command flow 152 
LOAD macro 24 
loader 
CMS 80 
data base 78 
input restrictions 80 
loader tables, CMS 14 
loading 
CMS, from card reader 45 
text files 67 
low-storage DMSFREE nucleus free 
storage area 14 
low-storage DMSFREE user free 
storage area 
low~storage nucleus chain 118 
low~storage user chain 118 
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machine carriage control 
characters) 108 
machine check, interrupt, in 
CMS 11 
macro library 
CMS 221 
CMS/DOS 229 
macros 
control block manipulation, 
VSAM 135 
GENCB 135 
I70 
CHECK 136 
ENDREQ 135 
ERASE 135 
GET 135 
POINT 135 
PUT 135 
MODCB 135 
oS 135 
SHOWCB 135 
TESTCB 135 
maintaining interactive session, 
CMS 51 
master file directory 
CMS 88, 98 
structure 8:9 
method of operation, for EXEC 2 
modules 184 
miscellaneous CMS functions 179 
MODCB processing 135 
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module antry point directory, 
CMS 190 

module flow description, for the 
new VM/SP editor 5 

MOVEFILE command flow 151 
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named system initialization 47 
named system, modifying one with 
the IMAGEMOD command 47 
non-CMS operating environments)9 129 
NOTE macro 27 
Nth chain link, format 86 
nucleus 
free storage, allocation 120 
storage copy of 45 
nucleus (CMS) 14 
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OPEN/OPENJ macros) 25 
OPEN, OS VSAM, simulation of 134 
operating environments 
non-CMS, access method support 
for 129 
Operating System 
See 0S (Operating System) 
operation 
of DMSINT 53 
of DMSITS 54 
organization, virtual disk 85 
OS (Operating System) 
control block functions, CMS 
simulation of 143 
data management simulation 21 
data sets, reading 31 
formatted files 28 
handling 
files on CMS disks 21 
files on OS or DOS disks 21 
macros 
ABEND 24 
ATTACH 26 
BLDL 25 
BSP 27 
CHAP 26 
CHECK 27 
CHKPT 27 
CLOSE/TCLOSE 25 
DCB 22, 27 
DCBD 22 
DELETE 24 
DEQ 26 
description of 23 
DETACH 27 
DEVTYPE 25 
ENQ 26 
EXIT 23 
EXTRACT 26 
FEOV 25 
FIND 25 
FREEDBUF 26 
FREEMAIN 24 
FREEPOOL 24 
GET 29 
GETMAIN 23 
GETMAIN/FREEMAIN 24 
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GETPOOL 24 
IDENTIFY 26 
LINK 24 
LOAD 24 
NOTE 27 
OPEN/OPENJ 25 
PGRLSE 27 
POINT 27 
POST 23 
PUT 29 
PUTX 29 
RDJFCB 27 
READ 29 
RESTORE 24 
RETURN 23 
SAVE 22 
SNAP 26 
SPIE 24 
STAE 27 
STAX 27 
STIMER 26 
STOW 25 
SYNADAF 27 
SYNADRLS 27 
TCLEARQ 27 
TGET/TPUT 27 
TIME 24 
TTIMER 26 
under CMS 21 
WAIT 23 
WRITE 29 
WTO/WTOR 25 
XCTL 24 
XDAP 23 
VSAM 
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